8.2. Shared library support files

If your package contains files whose names do not change with each change in the library shared object version, you must not put them in the shared library package. Otherwise, several versions of the shared library cannot be installed at the same time without filename clashes, making upgrades and transitions unnecessarily difficult.

It is recommended that supporting files and run-time support programs that do not need to be invoked manually by users, but are nevertheless required for the package to function, be placed (if they are binary) in a subdirectory of /usr/lib, preferably under /usr/lib/package-name. If the program or file is architecture independent, the recommendation is for it to be placed in a subdirectory of /usr/share instead, preferably under /usr/share/package-name. Following the package-name naming convention ensures that the file names change when the shared object version changes.

Run-time support programs that use the shared library but are not required for the library to function or files used by the shared library that can be used by any version of the shared library package should instead be put in a separate package. This package might typically be named libraryname-tools; note the absence of the soversion in the package name.

Files and support programs only useful when compiling software against the library should be included in the development package for the library. 6

6

For example, a package-name-config script or pkg-config configuration files.