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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 8, 2012 at 12:34 AM, Bob Friesenhahn
<bfriesen@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 7 Feb 2012, Lucas De Marchi wrote:
>
>>> 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.
>>
>>
>> Yes. We can always learn. It seems that this is not the case here.
>> There are other projects releasing like this and no one pointed out to
>> a reasonable argument against it. That means these arguments are not
>> valid in our case:
>>
>> a) It's not what libtool's manual says to do
>> b) In other architectures major number is not always c - a.
>>
>> That's because libkmod (like in other projects that do the same
>> release scheme) we are very tied to Linux, and being portable is not a
>> concern.
>
>
> Ok.
>
>
>>> 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.
>>
>>
>> No, quite the opposite. It doesn't follow libtool's manual, but it
>> does follow "ELF rules", ld and ld.so. On a API and ABI break the
>> soname is bumped according to libtool rules. And it doesn't matter if
>> it goes from libkmod.so.1 to libkmod.so.151 or if it goes to
>> libkmod.so.2. soname was bumped. major was bumped. Skipping all the
>> numbers between the majors seems like craziness.
>
>
> Numbers are free.  Only people who build the software or binary packages
> ever really see the numbers (if they care to look).

Yet IMO (which is shared with other projects) it doesn't reflect the
history of the project. There wasn't 151 API/ABI versions.


>>> 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.
>>
>>
>> As far as I understand, we are following "ELF rules". We are just not
>> following what libtool manual says.
>
>
> Ok.
>
> It seems that your project's unusual behaviour has brought unwanted

Not that unusual.

> attention to it from a highly-regarded and quite prolific Linux software
> developer (Jan Engelhardt).  Your project seems quite useful so it may be
> wise to keep up appearances (in spite of the annoyance) so that Linux
> distributions don't question if they should depend on it.

They can always question and I'll sure accept patches that are useful
and fix bugs. However I prefer ditching the annoyances, i.e. not
maintaining cruft, than keeping up appearances.


Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux