mNo edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
=== Packaging Shared Libraries === | === Packaging Shared Libraries === | ||
Wherever possible, libraries should be created with versioning in the filename, and provide a set of unversioned symlinks in a -devel file. In the case that a package only | If a library is providing resources that other packages may need at compile or runtime, it should be installed directly to the default library search path. Wherever possible, these libraries should be created with versioning in the filename, and provide a set of unversioned symlinks in a -devel file. In the case that a package only contains unversioned libraries, they may be included in the non-devel base packages. | ||
If a | According to the [http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA FHS] | ||
<pre>Applications may use a single subdirectory under /usr/lib. If an application uses | |||
a subdirectory, all architecture-dependent data exclusively used by the application must | |||
be placed within that subdirectory.</pre> | |||
This means that subdirectories in %{_libdir} are for libraries that are not intended to be used by other programs, users, scripts, etc. Applications may create a folder in %{_libdir} for libraries that are exclusively used by that application. For example, gstreamer and perl create their own subdirectories to store plugin libraries. These types plugin libraries are usually loaded by a program at runtime, and in many cases they don't need to be on the system's library search path. If libraries are installed into a subdirectory and do need to be on the system library search path, an entry in /etc/ld.so.conf.d/ may be created to add a subdirectory to the ld search path. Packages may NOT modify /etc/ld.so.conf. If program foo installs libraries to /usr/lib/foo, it may create /etc/ld.so.conf.d/foo.conf containing the line /usr/lib/foo. Libraries in %{_libdir} subdirectores do not need versioning in their filenames. | |||
Revision as of 03:05, 6 January 2010
This can be added to the Shared Libraries section of the Packaging Guidelines, perhaps as a subsection called "Packaging Shared Libraries"
If a library is providing resources that other packages may need at compile or runtime, it should be installed directly to the default library search path. Wherever possible, these libraries should be created with versioning in the filename, and provide a set of unversioned symlinks in a -devel file. In the case that a package only contains unversioned libraries, they may be included in the non-devel base packages.
According to the FHS
Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory.
This means that subdirectories in %{_libdir} are for libraries that are not intended to be used by other programs, users, scripts, etc. Applications may create a folder in %{_libdir} for libraries that are exclusively used by that application. For example, gstreamer and perl create their own subdirectories to store plugin libraries. These types plugin libraries are usually loaded by a program at runtime, and in many cases they don't need to be on the system's library search path. If libraries are installed into a subdirectory and do need to be on the system library search path, an entry in /etc/ld.so.conf.d/ may be created to add a subdirectory to the ld search path. Packages may NOT modify /etc/ld.so.conf. If program foo installs libraries to /usr/lib/foo, it may create /etc/ld.so.conf.d/foo.conf containing the line /usr/lib/foo. Libraries in %{_libdir} subdirectores do not need versioning in their filenames.