From Fedora Project Wiki
(Initial copy of the current guidelines)
 
No edit summary
 
Line 1: Line 1:
== Duplication of system libraries ==
== Bundling and Duplication of system libraries ==
 
A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. This prevents old bugs and security holes from living on after the core system libraries have been fixed.
 
In this RPM packaging context, the definition of the term 'library' includes: compiled third party source code resulting in shared or static linkable files, interpreted third party source code such as Python, PHP and others. At this time JavaScript intended to be served to a web browser on another computer is specifically exempted from this but this will likely change in the future.
 
Note that for C and C++ there's only one "system" in Fedora but for some other languages we have parallel stacks.  For instance, python, python3, jython, and pypy are all implementations of the python language but they are separate interpreters with slightly different implementations of the language.  Each stack is considered its own "system" and can each contain its own copy of a library.
 
Some packages may be granted an exception to this. Please see the [[Packaging:No Bundled Libraries|No Bundled Libraries]] page for rationale, the process for being granted an exception, and the requirements if your package is bundling.
 
For information on how to remove bundled libraries, see: [[Packaging:Treatment_Of_Bundled_Libraries|Treatment Of Bundled Libraries]].
 


Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.


== Bundling of multiple projects ==
All packages whose upstreams allow them to be built against system libraries must be built against system libraries.
Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.


However, when this is unavoidable, packagers must apply for a Bundling Exception with the Fedora Packaging Committee. For more information on Bundling and applying for a Bundling Exception, please read [[Packaging:No_Bundled_Libraries]].
All packages whose upstreams have no mechanism to build against system libraries may opt to carry bundled libraries, but if they do, they must include <code>Provides: bundled(<libname>) = <version></code> in their RPM spec file.  In addition, packages whose upstreams have no mechanism to build against system libraries must be contacted publicly about a path to supporting system libraries. If upstream refuses, this must be recorded in the spec file, either in comments placed adjacent to the <code>Provides:</code> above, or in an additional file checked into the SCM and referenced by a comment placed adjacent to the <code>Provides:</code> above.


=== Avoid bundling of fonts in other packages ===
=== Avoid bundling of fonts in other packages ===
Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging:FontsPolicy|1]]), and should never be packaged in a private application directory instead of the system-wide font repositories.
Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging:FontsPolicy|1]]), and should always be packaged in the system-wide font repositories instead of private application directories.
For more information, see: [[Packaging:FontsPolicy#Package_layout_for_fonts]].
For more information, see: [[Packaging:FontsPolicy#Package_layout_for_fonts]].

Latest revision as of 05:43, 8 October 2015

Bundling and Duplication of system libraries

Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.

All packages whose upstreams allow them to be built against system libraries must be built against system libraries.

All packages whose upstreams have no mechanism to build against system libraries may opt to carry bundled libraries, but if they do, they must include Provides: bundled(<libname>) = <version> in their RPM spec file. In addition, packages whose upstreams have no mechanism to build against system libraries must be contacted publicly about a path to supporting system libraries. If upstream refuses, this must be recorded in the spec file, either in comments placed adjacent to the Provides: above, or in an additional file checked into the SCM and referenced by a comment placed adjacent to the Provides: above.

Avoid bundling of fonts in other packages

Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines (1), and should always be packaged in the system-wide font repositories instead of private application directories. For more information, see: Packaging:FontsPolicy#Package_layout_for_fonts.