Re: bad lintian warning?
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
Reply to: