Packaging Static Libraries
- In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists.
- We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged:
- Static libraries and shared libraries. In this case, the static libraries must be placed in a *-static subpackage. Separating the static libraries from the other development files in *-devel allow us to track this usage by checking which packages
BuildRequirethe *-static package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries. - Static libraries only. When a package only provides static libraries you can place all the static library files in the *-devel subpackage. When doing this you also must have a virtual Provide for the *-static package:
%package devel
Provides: foo-static = %{version}-%{release}
Packages which explicitly need to link against the static version must BuildRequire: foo-static, so that the usage can be tracked.
- If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the *-devel subpackage. The devel subpackage must have a virtual Provide for the *-static package, and packages dependent on it must
BuildRequirethe *-static package.
Packaging Header Only Libraries
Certain libraries, especially some C++ template libraries, are header only libraries. Since the code is generated during compile time, they act just like static libraries and need to be treated as such.
Place all of the header files in the *-devel subpackage and then you must have a virtual Provide for the *-static package:
%package devel
Provides: foo-static = %{version}-%{release}
Packages which use the header library must BuildRequire: foo-static, so that the usage can be tracked.
Do not use noarch
It may be tempting to make the header library package noarch, since the header files themselves are simply text. However, a library should have tests which should be run on all architectures. Also, the install process may modify the installed headers depending on the build architecture. For these reasons, header-only packages must not be marked noarch.
Statically Linking Executables
- Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to FESCO for approval.
- If you link statically against a library, add yourself to the initialcc list for the library so you can watch for any security issues or bug fixes for which you'd want to rebuild your package against a new version of the library. Here are instructions for making that request.
Programs which don't need to notify FESCo
- Programs written in OCaml do not normally link dynamically to OCaml libraries. Because of that this requirement is waived. (OCaml code that calls out to libraries written in C should still link dynamically to the C libraries, however.)
- If a library you depend on only provides a static version your package can link against it provided that you
BuildRequirethe *-static subpackage. Packagers in such a situation should be aware that if a shared library becomes available, that you should adjust your package to use the shared library.
Programs which have been granted exceptions
- yaboot has permission to link statically since it's a boot loader that uses e2fsprogs-libs to read the filesystem