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

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

 



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


[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