No edit summary |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
This can be added to the Shared Libraries section of the [[Packaging/Guidelines#Shared_Libraries| Packaging Guidelines]], perhaps as a subsection called "Packaging Shared Libraries" | This can be added to the Shared Libraries section of the [[Packaging/Guidelines#Shared_Libraries| Packaging Guidelines]], perhaps as a subsection called "Packaging Shared Libraries" | ||
==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> | |||
/usr/lib includes object files, libraries, and internal binaries that are not | |||
intended to be executed directly by users or shell scripts. | |||
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> | |||
Applications in Fedora may create a subdirectory in %{_libdir} for libraries used exclusively by the application installing them. 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. | |||
Certain build systems (like cmake) create build files and install them to an application's %{_libdir} subdirectories (see packages avogadro, vtk, cgal, automoc, etc.) These types of build specific files should be put in -devel packages. | |||
Latest revision as of 03:23, 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
/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. 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.
Applications in Fedora may create a subdirectory in %{_libdir} for libraries used exclusively by the application installing them. 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.
Certain build systems (like cmake) create build files and install them to an application's %{_libdir} subdirectories (see packages avogadro, vtk, cgal, automoc, etc.) These types of build specific files should be put in -devel packages.