[Mageia-dev] Utter frustration

Sat Dec 1 03:04:53 CET 2012

Op vrijdag 30 november 2012 12:59:25 schreef Anne Wilson:
+>> On 30/11/12 12:26, Frank Griffin wrote:
+>>> On 11/30/2012 07:13 AM, Anne Wilson wrote:
+>>>> Before doing all that, can you explain the significance of the
+>>>> suffixes here?
+>>>>
+>>>> ls /usr/lib/ | grep powerdevil
+>>>> libpowerdevilconfigcommonprivate.so.4@
+>>>> libpowerdevilconfigcommonprivate.so.4.10.0*
+>>>> libpowerdevilcore.so.0@ libpowerdevilcore.so.0.1.0*
+>>>> libpowerdevilui.so.4@ libpowerdevilui.so.4.10.0*
+>>> Library naming conventions use several, actual version, e. g.
+>>> 4.10.0, major version, e. g. 4, and a generic name, e. g.
+>>> libxxx.so.  The last two are usually symlinked to the first.
+>>>
+>>> The major version usually signals an ABI difference or some other
+>>> major difference, e. g. new function, from the previous version.
+>>> The actual version changes whenever any change is made.  Developers
+>>> use the major version if their code is dependent on that major
+>>> version, but just use the generic name if any version will do.
+>>>
+>>> In this way, the majority of packages using the library just ask
+>>> for libxxx.so, and don't have to be rebuilt or have their makefiles
+>>> or spec modified when the library changes.  A few packages, which
+>>> are dependent on a specific version, ask for libxxx.so.N (or
+>>> higher), and these have to be changed when the major version they
+>>> require is released.  A very very few packages are dependent on the
+>>> actual version, and these may have to change more often.
+>> I assume the starred ones are actually in use - what's the
+>> significance of '@'?  I'm not sure I've really understood this.
+>>
+OK, say libXXX provides functions funcA, funcB, and funcC.  The library 
+developer releases version 1.0.0, and the package installs 
+libXXX.so.1.0.0 and symlinks libXXX.so.1.0, libXXX.so.1.0, and libXXX.so 
+to this.
+
+Now, the library developer fixes some minor bugs.  They don't involve 
+any changes to the binary interface (ABI), e. g. they don't change the 
+datatypes of any of the parameters to the three functions, and they 
+don't change the number of parameters to any of them.  So any 
+application that used version 1.0.0 should work with the new version.  
+The developer calls this version 1.0.1, and when the libXXX package 
+installs, it adds libXXX.so.1.0.1, and changes the libXXX.so.1 and 
+libXXX.so symlinks to point to that. Applications which used 1.0.0 by 
+asking for libXXX.so or libXXX.so.1 don't see any difference.  If an 
+application specifically asked for libXXX.so.1.0, it gets the older 
+version (provided you didn't unistall it).  Same goes for an application 
+that specifically asks for libXXX.1.0.0.
+
+Now, suppose the library developer adds funcD to the library, and 
+doesn't change the ABI (Application Binary Interface) of A/B/C.  He 
+calls the new package 1.1.0, and when it installs, it installs 
+libXXX.so.1.1.0, adds a libXXX.so.1.1 symlink to it, and changes the 
+linXXX.so symlink accordingly.  Applications that used 1.0.0 or 1.0.1 
+could only use funcA/B/C, and will work exactly as they always did with 
+the new version.  But a new application that uses funcD won't work with 
+the older versions, so its package has to say that it requires 1.1.0 or 
+later.
+
+Now the library developer finds a serious day-zero bug in funcA. Maybe 
+one of the parameters was originally an int when it should have been a 
+time_t, and the library doesn't work with newer system libraries because 
+time_t has changed from an int to an int64.  This means that the ABI 
+changes.  Applications compiled to use the older libraries won't work 
+with the newer versions.  Applications written to use the newer version 
+won't work with the older versions.
+
+So the library developer bumps the major version and releases 2.0.0, 
+along with an advisory that any applications with dependencies on the 
+ABI changes from 1.x.x. -> 2.0.0 must either be modified to use the 
+newer ABI (in which case they can continue to use libXXX.so and 
+requiring >=libXXX.so.2) or must have their spec file modified to 
+require =libXXX.so.1 or <=libXXX.so.1.1.
+
+Any app that just asks for libXXX.so has to be modified to use the new 
+funcA ABI whether it uses funcD or not.  Any app that uses libXXX.so and 
+uses funcD and the original ABI for funcA has to be changed to use 
+libXXX.so.1.1 and require <=1.1 or else be changed to use the the new ABI.
+
+As time goes on, either the source code or the makefiles/specfiles for 
+old apps have to be changed in one way or the other.  But the intent is 
+that as many old apps as possible can use libXXX.so until circumstances 
+make that impossible.  At that point. the makefile/specfile has to 
+change in a minor way, if you're willing to have multiple versions of 
+libXXX installed.  Or, if the app is under active development, the 
+developer can choose to update the source to conform to the newer ABI 
+and update the makefile/specfile to require at least the version that 
+supports that ABI.
+