(debian-policy.info)Dependencies between the library and other packages

---

Prev: Dependencies between the packages of the same library Up: Shared libraries

---

Enter node , (file) or (file)node

8.6 Dependencies between the library and other packages
=======================================================

If a package contains a binary or library which links to a shared
library, we must ensure that, when the package is installed on the
system, all of the libraries needed are also installed.  These
dependencies must be added to the binary package when it is built, since
they may change based on which version of a shared library the binary or
library was linked with even if there are no changes to the source of
the binary (for example, symbol versions change, macros become functions
or vice versa, or the binary package may determine at compile-time
whether new library interfaces are available and can be called).  To
allow these dependencies to be constructed, shared libraries must
provide either a ‘symbols’ file or a ‘shlibs’ file.  These provide
information on the package dependencies required to ensure the presence
of interfaces provided by this library.  Any package with binaries or
libraries linking to a shared library must use these files to determine
the required dependencies when it is built.  Other packages which use a
shared library (for example using ‘dlopen()’) should compute appropriate
dependencies using these files at build time as well.

The two mechanisms differ in the degree of detail that they provide.  A
‘symbols’ file documents, for each symbol exported by a library, the
minimal version of the package any binary using this symbol will need.
This is typically the version of the package in which the symbol was
introduced.  This information permits detailed analysis of the symbols
used by a particular package and construction of an accurate dependency,
but it requires the package maintainer to track more information about
the shared library.

A ‘shlibs’ file, in contrast, only documents the last time the library
ABI changed in any way.  It only provides information about the library
as a whole, not individual symbols.  When a package is built using a
shared library with only a ‘shlibs’ file, the generated dependency will
require a version of the shared library equal to or newer than the
version of the last ABI change.  This generates unnecessarily
restrictive dependencies compared to ‘symbols’ files if none of the
symbols used by the package have changed.  This, in turn, may make
upgrades needlessly complex and unnecessarily restrict use of the
package on systems with older versions of the shared libraries.

‘shlibs’ files also only support a limited range of library SONAMEs,
making it difficult to use ‘shlibs’ files in some unusual corner cases.
(1)

‘symbols’ files are therefore recommended for most shared library
packages since they provide more accurate dependencies.  For most C
libraries, the additional detail required by ‘symbols’ files is not too
difficult to maintain.  However, maintaining exhaustive symbols
information for a C++ library can be quite onerous, so ‘shlibs’ files
may be more appropriate for most C++ libraries.  Libraries with a
corresponding udeb must also provide a ‘shlibs’ file, since the udeb
infrastructure does not use ‘symbols’ files.

Generating dependencies on shared libraries

Shared library ABI changes

The symbols system

The shlibs system

   ---------- Footnotes ----------

   (1) A ‘shlibs’ file represents an SONAME as a library name and
version number, such as ‘libfoo VERSION’, instead of recording the
actual SONAME. If the SONAME doesn’t match one of the two expected
formats (‘libfoo-VERSION.so’ or ‘libfoo.so.VERSION’), it cannot be
represented.