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