[Debian-med-packaging] New Sight version

Tue Jun 28 16:14:24 BST 2022

Hi Flavien,

Am Tue, Jun 28, 2022 at 10:40:18AM +0200 schrieb Flavien Bridault:
> I have started working on the issues you pointed out.
> 
> The build failure with gcc12 is fixed (I was very lucky to guess it, but I
> am really not sure to understand why it failed in the first place...).

Cool!

> I've addressed most lintian warnings (not info yet...)

Nice.

> but I struggle a bit
> with the last one, about package sonames.
> 
> I am not sure to understand how I should fix it. I use a semantic version
> number for Sight. Usually we try to only break binary compatibility with
> major version (19, 20, 21). Lately we also broke binary compatibility with
> minor versions, but this should not happen.

Thanks a lot for the explanation.

> Whatever, currently in CMake we
> define this property to set the library so version.
> 
> set_target_properties(
> ${SIGHT_TARGET}PROPERTIESVERSION${PROJECT_VERSION}SOVERSION${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}
> )
> So as far I understand with the snippet given on the lintian warning, it
> would expects the package to be named libsight22.0... So two questions:
> 
> 1. We do not have a library libsight.so but many libsight_name.so. Is
>    this a problem for lintian or would I need to split into multiple
>    packages ?

If a library package contains more than one libXYZ.so you can never
satisfy lintian.  In this case it might make sense to use a
lintian-override (or just ignore the warning).  A typical library
package contains a single lib*.so file and lintian is checking for
this.  However, in some cases it makes sense to bundle several small
libraries into one package and lintian is stubborn enough to tell you
that it does not like it.  Finally the developer is more intelligent
what makes sense or not than lintian (hopefully ;-) ).

> 2. Is the solution to rename the package to libsight22.0 ? Or maybe if
>    I manage to be a bit stricter with development rules, stick to
>    libsight22 ? If yes, does this mean on every major upgrade, I need
>    to change the name of the package ?

Its finally your choice whether you pick the name libsight22 or
libsight22.0.  As I tried to express its not possible to satisfy lintian
in this case and the package name is a matter of taste here.  But yes,
you should change the name of the package if the SONAME is bumped.  This
enables parallel installations of different library versions.

> Is it ok then, to conflict with
>    the previous version to not let the user install two versions.

No, its the very point to *enable* the user having two versions of the
shared library installed to rename the binary package name after a
SONAME bump.  Assume the user has installed some binary that is linked
against the old version.  So the package should remain but it should
not block the new version.

> I ask
>    this because I am really not sure this is supported currently, and
>    frankly I don't  really see the interest, and I don't have spare
>    time to work on supporting that.

I admit that sight is probably not the kind of library which needs all
this detailed considerations that are needed for shared libraries that
are used by several applications.  In fact as far as I can see its only
used by the applications shipped in the same source package.  So well, I
think its to some extend OK to leave it as is and be "sloppy" in terms
of the library packaging guide and simply keep it as is by ignoring the
lintian warning.

> Thank you for your time and advice,

You are welcome

      Andreas.

> Kind regards,
> 
> *Dr. Flavien BRIDAULT*
> Director of Software Development
> IRCAD France & IRCAD Africa
> 
> flavien.bridault at ircad.fr <mailto:flavien.bridault-louchez at ircad.fr>
> Tél. : +33 (0)3 88 119 201
> 		IRCAD France
> http://www.ircad.fr/
> http://www.ircad.africa/ <http://www.ircad.fr/>
> 
> Suivez l'IRCAD sur Facebook
> <http://www.facebook.com/pages/IRCAD/193785273990141>
> 
> *IRCAD France*
> Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex -
> FRANCE
> 
> Le 17/06/2022 à 21:25, Étienne Mollier a écrit :
> > Hi Flavien,
> > 
> > Flavien Bridault, on 2022-06-14:
> > > A little "up" in this thread, if someone could have a look at the update of
> > > Sight 21.1 and upload it if it looks ok...
> > Thanks for the nudge!  Sorry for the delay.
> > 
> > > Le 11/05/2022 à 09:01, Flavien Bridault a écrit :
> > > > I updated Sight to 21.1.1 and updated all patches as usual. It looks
> > > > good to me for upload.
> > > > 
> > > > Please verify and upload it if you think it is good enough.
> > I pulled your changes and ran a build, plus a few tools to help
> > review.  Running `lintian --display-info --pedantic`, please
> > have a look at the lintian warnings, and see whether they can be
> > addressed.  I notably noticed the following:
> > 
> > 	W: libsight: duplicate-font-file usr/share/sight/viz_scene3d/Media/fonts/DejaVuSans.ttf also in (fonts-dejavu-core)
> > 	W: libsight: unusual-interpreter python [usr/share/sight/viz_scene3d/Media/materials/genDefaultMaterial.py]
> > 
> > Note that there are many more messages.  You may override items
> > if they are not actionable, and document why they are overridden
> > in the corresponding lintian-overrides file.  (Note that I
> > understood the "elf-error In program headers:" is a lintian bug
> > on debug symbols packages, so you may just ignore that for the
> > time being in case it crops up with your lintian version.)
> > 
> > You can also run blhc to check the build log, to make sure
> > standard Debian build flags are propagated appropriately.  At
> > the moment, it reports that flags propagated through LDFLAGS are
> > missing in several instances (but maybe there is a good reason
> > for that, in which case you can ignore-line-regexp and document
> > why).
> > 
> > If you have the opportunity to do so, you may want to address
> > the bug #1013036[1]; this is not urgent yet, but will be needed
> > before debian 12 release.  After looking at the build log[2] and
> > the help page to porting to gcc-12[3], the issue didn't look
> > exactly obvious to me though.
> > 
> > [1]:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013036
> > [2]:http://qa-logs.debian.net/2022/06/09/gcc12/sight_21.0.0-4_unstable_gcc12.log
> > [3]:https://gcc.gnu.org/gcc-12/porting_to.html
> > 
> > In general, you may want to have a look at the package tracker
> > to have a summary of some of the different issues[4] in the
> > existing unstable version you might want to address.
> > 
> > [4]:https://tracker.debian.org/pkg/sight
> > 
> > The package looks otherwise in good shape to me, and I would be
> > happy to upload (or happy to be beaten at uploading by someone
> > else) once you address the warnings I pointed to and ready the
> > debian/changelog for upload to unstable instead of UNRELEASED.
> > 
> > Thank you for your contributions!
> > 
> > Have a nice day,  :)

> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de