From Fedora Project Wiki
(Reset to existing Libraries and Applications guidelines)
Line 1: Line 1:
== Desktop files ==
== Libraries and Applications ==


If a package contains a GUI application, then it needs to also include a properly installed .desktop file.  For the purposes of these guidelines, a GUI application is defined as any application which draws a window and runs from within that window.  Installed .desktop files MUST follow the [http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec]  , paying particular attention to validating correct usage of Name, GenericName, [http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] ,
Many language- or domain-specific guidelines refer to "libraries",
[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]
"modules", "plug-ins" or other terms specific to the language or
entries.
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.


=== Application independence ===
=== Library or Application? ===


Applications should be installable independently when this is technically feasible. A package should generally not depend on a package containing an application except if it functions as a plug-in for that application. If a source package provides multiple applications, those applications should be packaged in separate subpackages. If a source package provides both a library and also an associated application, that application should be packaged in a subpackage in order to allow other applications to depend on only the library and not the associated application. Installing an application that depends on a library or service should not automatically pull in other applications associated with that library or service. Packages that contain a visible .desktop file (a .desktop file that does not contain the line <code>NoDisplay=true</code>) should generally not have a Requires, Recommends, or Supplements on any other package containing a visible desktop file, directly or indirectly.
* 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:
 
# 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.
# 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.

Revision as of 01:09, 3 May 2018

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.

Retrieved from "https://fedoraproject.org/w/index.php?title=PackagingDrafts/IndependentApplications&oldid=517484"