On 21/05/12 10:02, Andrey Rahmatullin wrote: > On Mon, May 21, 2012 at 09:03:09AM +0000, Daniel Pocock wrote: >>>> b) I notice the verbose output (on the mentors summary page) >>>> shows an SONAME in a slightly different format: >>>> >>>> usr/lib/librutil-1.8.so.0.0.0 usr/lib/librutil-1.8.so >>>> >>>> Notice: librutil-1.8.so, while the -dev package creates a symlink >>>> in the form librutil.so >>> Yes, that's the problem. Lintian cuts out everything after ".so" >>> when searching for the dev symlink while libtool with -release >>> doesn't include the release number in the dev symlink (see also >>> info libtool "7.4 Managing release information"). If you encode the >>> library version in the library name, you are supposed to specify >>> that version when linking, otherwise it's pointless. Note that the >>> libtool example (libbfd-2.9.0.so) doesn't >> >> Ok, so if people are supposed to specify the version when linking, >> then I should do these two things: >> >> - - not ship the librutil.so symlink at all in the -dev package? > If you drop -version-info and use -release to declare ABI breaks you will > have a libfoo.so symlink and you will need to link against -lfoo. If you > want to have -version-info for ABI breaks and -release for something > different (parallel APIs?) to link against -lfoo-1.8 then maybe you need > some manual work, I'm not sure about such scenarios. Please rethink what > version schemes do you want to use.
Linking against -lfoo is acceptable, so I've just dropped `-version-info 0:0:0' Now I just use `-release 1.8' >> - - make a lintian override to suppress the warning, with a comment to >> explain I am using -release deliberately for resiprocate? > I'm not sure you want to keep the current names for the lib and the dev > symlink (but if you do, then probably you should override the warning). > Now I get exactly the type of filenames described in the manual: http://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html#Release-numbers e.g. usr/lib/librutil.so -> usr/lib/librutil-1.8.so The .0.0.0 suffixes are gone, but I still have the lintian warnings As this scenario is valid from the libtool manual, it is acceptable to use the override for lintian? >>> have a soversion while your libs have -version-info 0:0:0 in >>> addition to -release 1.8 and that's why the libs are named >>> libfoo-1.8.so.0.0.0 instead of more common libfoo-1.8.so. >> >> I realize -version-info is redundant here, but is it prohibited to set >> - -version-info when using -release? The libtool manual is not explicit >> about whether I can mix them. >> http://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html#Release-numbers > The manual seems to talk about the usual case with compatible changes > (-version-info) vs the less usual case with each version incompatible with > others (-release). I don't know how is libtool intended to work with both > arguments provided, but in you case it doesn't include -release in the dev > symlink name which means you cannot have different dev libraries > coinstalled. > >> I thought setting -version-info would allow for minor changes, e.g. >> >> - - a 1.8.1 release may have -version-info 0:1:0 >> - - a 1.8.5 release might have -version-info 1:0:0 >> >> but all 1.8.x releases would have SONAME librutil-1.8.so > To be honest I don't see much reason to have different file names for libs > with the same soname as in the real world you end up using the newest one > anyway (I'm speaking only about ELFs on Linux though). > This has already been discussed some time ago on this list and upstream, and it was agreed to be the most suitable solution for this particular package to use libtool -release: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2012-January/003330.html http://list.resiprocate.org/archive/resiprocate-devel/msg07355.html http://lists.debian.org/debian-mentors/2009/07/msg00130.html -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fba617b.3010...@trendhosting.net
