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: commit e479598b7d19ae7be45bf5329d6e4df32d646c16 diff --git a/Makefile.am b/Makefile.am index 69ab986..172d2ff 100644 --- a/Makefile.am +++ b/Makefile.am -LIBKMOD_CURRENT=4 +LIBKMOD_CURRENT=2 LIBKMOD_REVISION=0 -LIBKMOD_AGE=3 +LIBKMOD_AGE=0 (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". They base their decision on the assumption that libtool on Linux always uses the "MAJOR = CURRENT - AGE" computation scheme, and that it would therefore be ok to go from C=4,A=3 to C=2,A=0 just so that they have a nice sequence of libkmod.so.1, libkmod.so.2, because they do not seem to like the appearance of libkmod.so.5 in their system which would be emitted if C=5,A=0 had been chosen. It is my position that assuming any particular scheme for MAJOR chosen by libtool should not be relied upon, just as assumptions in general are a habit with a certain badness level, depending on the situation. The following patch tries to exemplify the problem that compiling both kmod v2 and kmod v5 will cause colliding libkmod.so.2s to be emitted that have different interfaces. Sinister voices will claim my libtool would be broken, but would it be? Who is to say that I cannot have a Linux kernel-based system, and use e.g. BSD's MAJOR scheme instead? Every src package that adheres to libtool versioning (i.e. as per libtool.info) should not have a problem regardless of how CURRENT/AGE is encoded in the filename. --- libltdl/config/ltmain.m4sh | 8 +------- libltdl/config/ltmain.sh | 8 +------- 2 files changed, 2 insertions(+), 14 deletions(-) Index: libtool-2.4.2/libltdl/config/ltmain.m4sh =================================================================== --- libtool-2.4.2.orig/libltdl/config/ltmain.m4sh +++ libtool-2.4.2/libltdl/config/ltmain.m4sh @@ -6626,7 +6626,7 @@ func_mode_link () versuffix=".$current.$revision"; ;; - freebsd-elf) + freebsd-elf | linux) major=".$current" versuffix=".$current" ;; @@ -6660,12 +6660,6 @@ func_mode_link () versuffix="$major.$revision" ;; - linux) # correct to gnu/linux during the next big refactor - func_arith $current - $age - major=.$func_arith_result - versuffix="$major.$age.$revision" - ;; - osf) func_arith $current - $age major=.$func_arith_result Index: libtool-2.4.2/libltdl/config/ltmain.sh =================================================================== --- libtool-2.4.2.orig/libltdl/config/ltmain.sh +++ libtool-2.4.2/libltdl/config/ltmain.sh @@ -7413,7 +7413,7 @@ func_mode_link () versuffix=".$current.$revision"; ;; - freebsd-elf) + freebsd-elf | linux) major=".$current" versuffix=".$current" ;; @@ -7447,12 +7447,6 @@ func_mode_link () versuffix="$major.$revision" ;; - linux) # correct to gnu/linux during the next big refactor - func_arith $current - $age - major=.$func_arith_result - versuffix="$major.$age.$revision" - ;; - osf) func_arith $current - $age major=.$func_arith_result -- 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
