[Mageia-dev] Utter frustration

[Frank Griffin]

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.