Re: The case of libkmod's .so versioning attempts, and induced collisions

[Vincent Torri]

On Tue, Feb 7, 2012 at 3:03 AM, Bob Friesenhahn
<address@hidden> wrote:
> On Tue, 7 Feb 2012, Jan Engelhardt wrote:
>
>> Much to my disappointment, I found that the newly-released libkmod v5
>> has made the following non-trivial change to its source tree, the latter
>> of which I want to bring to attention:
>
> [stuff removed]
>
>> (The numbers are directly fed into libtool's -version-info argument.) As
>> you can see, the CURRENT number was decreased, which, according to
>> common libtool sense, is not something that one should normally do. Why
>> do I care? Well, I happen to be active in toying with system tools
>> (especially the ones I have to use sooner or later), as well as distro
>> packaging, with a preference to get things right.
>>
>> Unfortunately, I was unable to convince the kmod people of this fact.
>> Kay Sievers and Lucas De Marchi's argumentation is that (a) kmod is
>> linux-only and (b) there has 'never been a libkmod.so.2' before, or even
>> something about (c) not caring about GNU/"the mess that libtool is".
>
>
> Hopefully your intention is only to illustrate what projects should not do
> and not to submit a patch.  This libkmod project seems to be less than two
> months old and perhaps the developers still have a bit to learn about
> library versioning.
>
> While libtool does compute the name to apply to the library (using ELF
> rules), build-time (ld) and run-time (ld.so) linking is done via standard
> system tools and so they determine how the naming gets used.
>
> ELF is where the rules come from, not libtool.  Libtool tries to make it
> easy to follow the ELF rules while working as best as possible with other
> schemes.

I'm a bit surprised of that modification, as I know the guys behind
libkmod, and they are good programmers.
I'll try to discuss with them about that

regards

Vincent