[Debian-med-packaging] insighttoolkit_3.20.0-11_amd64.changes REJECTED

[Michael Hanke]

On Sun, Jul 24, 2011 at 01:59:09PM -0500, Steve M. Robbins wrote:
> > > Reject Reasons:
> > > libinsighttoolkit3.20: lintian output: 'embedded-library usr/lib/libitkjpeg12.so.3.20.0: libjpeg', automatically rejected package.
> > > libinsighttoolkit3.20: If you have a good reason, you may override this lintian tag.
> > > libinsighttoolkit3.20: lintian output: 'embedded-library usr/lib/libitkjpeg16.so.3.20.0: libjpeg', automatically rejected package.
> > > libinsighttoolkit3.20: If you have a good reason, you may override this lintian tag.
> > > libinsighttoolkit3.20: lintian output: 'embedded-library usr/lib/libitkjpeg8.so.3.20.0: libjpeg', automatically rejected package.
> > > libinsighttoolkit3.20: If you have a good reason, you may override this lintian tag.
> > > libinsighttoolkit3.20: lintian output: 'embedded-library usr/lib/libitkopenjpeg.so.3.20.0: openjpeg', automatically rejected package.
> > > libinsighttoolkit3.20: If you have a good reason, you may override this lintian tag.
> 
> My understanding from the authors is that the jpeg libraries are
> heavily modified for use in ITK (and gdcm), so I'm going to override
> this tag and re-upload.

Hmm, haven't heard this yet. Is there any source where the modifications
are described? I'm asking because I routinely patch all software to
avoid linking to any of the foreign libs included in ITK/VTK -- I never
saw any change in behavior, never experienced any breakage of API.

I was under the impression that it is an exact rebuilt. If they modify
it we'd need to know why, and whether that is necessary in which
context, as it has a potential effect on any package the builds against
ITK in Debian. If modification is necessary, we'd need to know if that
should be applied to the actual Debian packages providing these libs.
Royal PITA, but...


> > in this context: http://bugs.debian.org/586997
> 
> I'm not sure the status of the NIfTI libs.  This bug suggests there
> are fixes applied to the ITK version.  It would be useful for someone
> to audit them and contribute them back to the NIfTI sources.

... and doing that for every upload of ITK from now on until the world
ends. I think it would be more efficient the remove ALL embedded libs
from ITK and always use the corresponding Debian packages. This way we
would notice if there is any breakage, and preserve the advantages of
the modular system that Debian is. Keeping the embedded libs hinders
propagation of fixes upstream, as nobody notices that something is
broken.

Looking at the particular case of nifticlib: the VCS of the nifticlib,
appears to have some patches from ITK flowing in (although not yet part
of a nifticlib release). I see that as another argument to remove the
embedded lib in ITK.


Toughts?

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de