From Fedora Project Wiki
(Better formatting, fix thinko.)
 
(2 intermediate revisions by 2 users not shown)
Line 3: Line 3:
Many language- or domain-specific guidelines refer to "libraries",
Many language- or domain-specific guidelines refer to "libraries",
"modules", "plug-ins" or other terms specific to the language or
"modules", "plug-ins" or other terms specific to the language or
domain ("libraries").  This is specifically important to package
domain.  This is specifically important to package
naming.  Some applications may include libraries, and some libraries
naming.  Some applications may include libraries, and some libraries
may include applications, so the distinction is not always clear.
may include applications, so the distinction is not always clear.
Line 9: Line 9:
=== Library or Application? ===
=== Library or Application? ===


* If a package includes only files, libraries, or executables which are intended to be imported or loaded into other code, it is alibrary and MUST be packaged as such.  (XXX Reference to application-specific naming.)
* If the primary purpose of a package is to provide executables to be run by users, it SHOULD be packaged as an application. If it also includes libraries which may be imported or linked to by other code, see [[#Mixed Use Packages]] below.
* If a package includes only executables and libraries used internally by that those executables, it is an application and MUST be packaged as such.  (XXX Need reference to naming guidelines for applications, which we don't specifically have.)
* If the primary purpose of a package is to provide libraries intended to be imported or loaded into other code, it is considered a library and MUST be packaged as such. If it contains utility programs that can be run by users as well, see [[#Mixed Use Packages]] below.
* If the primary purpose of a package is to provide executables to be run by users, but also includes libraries which may be imported by other code, then it is considered an application and in general SHOULD be packaged as an application.  However, see [[#Mixed Use Packages]] below.
* If the primary purpose of a package is to provide libraries intended to be imported or loaded into other code, it is considered a library and MUST be packaged as such. However, see [[#Mixed Use Packages]] below.


It is left to the packager to determine the primary purpose of a
It is left to the packager to determine the primary purpose of a
Line 22: Line 20:


Many packages, regardless of their primary purpose, include both
Many packages, regardless of their primary purpose, include both
applications and libraries.  There are a few options:
applications and libraries.  The following options are available to the packager:


# Split out into one or more subpackages the executables or libraries, following the relevant guidelines.
# Simply package as an application or a library and just include the libraries or executables in that package.
# Simply package as an application or a library and just include the libraries or executables in that package.
# Do #1 but also add a Provides: for the name of an application or library according to the regular packaging guidelines.
# Do #2 but also add a Provides: for the name of an application or library according to the regular packaging guidelines.
# Split out into one or more subpackages the executables or libraries, following the relevant guidelines.


If the executables have significant dependencies which the libraries
If the executables have any dependencies which the libraries
do not, then #3 MUST be followed.  Otherwise #2 or #3 SHOULD be
do not, then #1 MUST be followed.  Note that RPM itself may automatically
followed, but note that in some cases, RPM itself may automatically
add the necessary Provides: and these MUST not be duplicated in case #3.
add the necessary Provides: and these MUST not be duplicated. (XXX
This whole section is unwieldy.)

Latest revision as of 17:07, 22 September 2016

Libraries and Applications

Many language- or domain-specific guidelines refer to "libraries", "modules", "plug-ins" or other terms specific to the language or domain. This is specifically important to package naming. Some applications may include libraries, and some libraries may include applications, so the distinction is not always clear.

Library or Application?

  • If the primary purpose of a package is to provide executables to be run by users, it SHOULD be packaged as an application. If it also includes libraries which may be imported or linked to by other code, see #Mixed Use Packages below.
  • If the primary purpose of a package is to provide libraries intended to be imported or loaded into other code, it is considered a library and MUST be packaged as such. If it contains utility programs that can be run by users as well, see #Mixed Use Packages below.

It is left to the packager to determine the primary purpose of a package. Often times upstream will already have done this with their choice of naming and that choice SHOULD be followed by the Fedora packager.

Mixed Use Packages

Many packages, regardless of their primary purpose, include both applications and libraries. The following options are available to the packager:

  1. Split out into one or more subpackages the executables or libraries, following the relevant guidelines.
  2. Simply package as an application or a library and just include the libraries or executables in that package.
  3. Do #2 but also add a Provides: for the name of an application or library according to the regular packaging guidelines.

If the executables have any dependencies which the libraries do not, then #1 MUST be followed. Note that RPM itself may automatically add the necessary Provides: and these MUST not be duplicated in case #3.