A shared library is identified by the , which exists on the file system as a symlink pointing to the full name of the shared library. Run-time shared libraries, Section 8.1 describes how to do this. When linking a binary or another shared library against a shared library, the symlink is installed in the development package since it's only used when linking binaries or shared libraries.
This practice is vital to allowing clean upgrades from older versions of the package and clean transitions between the old ABI and new ABI without having to upgrade every affected package simultaneously.
The and binary package name need not, and indeed normally should not, change if new interfaces are added but none are removed or changed, since this will not break binaries linked against the old shared library.
Correct versioning of dependencies on the newer shared library by binaries that use the new interfaces is handled via the will take care of renaming things safely without affecting running programs, and attempts to interfere with this are likely to lead to problems.
Libraries, Section 10.2 should be read in conjunction with this section and contains additional rules for the files contained in the shared library packages. This allows several versions of the shared library to be installed at the same time, allowing installation of the new version of the shared library without immediately breaking binaries that depend on the old version.
Normally, the run-time shared library and its s do not change together, upgrading such a merged shared library package will be unnecessarily difficult because of file conflicts with the old version of the package.
When in doubt, always split shared library packages so that each binary package installs a single shared library.Every time the shared library ABI changes in a way that may break binaries linked against older versions of the shared library, the should change any time an interface is removed from the shared library or the signature of an interface (the number of parameters or the types of parameters that it takes, for example) is changed.Packages containing shared libraries must be constructed with a little care to make sure that the shared library is always available.This is especially important for packages whose shared libraries are vitally important, such as the C library (currently ).This section deals only with public shared libraries: shared libraries that are placed in directories searched by the dynamic linker by default or which are intended to be linked against normally and possibly used by other, independent packages.Shared libraries that are internal to a particular package or that are only loaded as dynamic modules are not covered by this section and are not subject to its requirements.