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.
