From Fedora Project Wiki
m (change application to one or both)
 
(7 intermediate revisions by 2 users not shown)
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.
domainThis 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 not generally depend on a package containing an application except if it functions as an 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 not have a Requires, Recommends, or Supplements on any other package containing a visible desktop file, directly or indirectly. Use Enhances and Suggests instead.
* 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. In this case one or both SHOULD
be packaged in subpackages in order to allow other applications to depend
on only the library and not the associated application(s). Installing an
application that depends on a library or service should not automatically
pull in other applications associated with that library or service.
 
=== Application Independence ===
 
Applications SHOULD be installable independently whenever this is technically feasible.
Packages that contain a visible .desktop file (a .desktop file that does not contain the line
<code>NoDisplay=true</code>) SHOULD NOT have a Requires, Recommends, or Supplements
on any other package containing a visible desktop file, directly or indirectly, unless the
dependency is required for technical reasons or truly makes sense to have.
For example, it would be reasonable for a video game level editor to
require the associated video game in order to function, or for an application's plugin to
require the associated application. But it would not be reasonable for an application that happens
to use a database library to depend on a database management application associated
with that library, or for an application that happens to use a particular programming language
to depend on management tools associated with that programming language.
 
If a source package provides multiple desktop applications, those
applications SHOULD be packaged in separate subpackages when feasible.

Latest revision as of 16:28, 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. In this case one or both SHOULD be packaged in subpackages in order to allow other applications to depend on only the library and not the associated application(s). Installing an application that depends on a library or service should not automatically pull in other applications associated with that library or service.

Application Independence

Applications SHOULD be installable independently whenever this is technically feasible. Packages that contain a visible .desktop file (a .desktop file that does not contain the line NoDisplay=true) SHOULD NOT have a Requires, Recommends, or Supplements on any other package containing a visible desktop file, directly or indirectly, unless the dependency is required for technical reasons or truly makes sense to have. For example, it would be reasonable for a video game level editor to require the associated video game in order to function, or for an application's plugin to require the associated application. But it would not be reasonable for an application that happens to use a database library to depend on a database management application associated with that library, or for an application that happens to use a particular programming language to depend on management tools associated with that programming language.

If a source package provides multiple desktop applications, those applications SHOULD be packaged in separate subpackages when feasible.