From Fedora Project Wiki

m (Remove pointless "new" from Addon Packages section. https://pagure.io/packaging-committee/issue/774)
(15 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Package Naming and Versioning Guidelines =
{{DISPLAYTITLE:Guidelines for Naming Fedora Packages}}
<div style="float: right; margin-left: 0.5em" class="toclimit-2">__TOC__</div>


'''Original Author:''' [[TomCallaway| Tom 'spot' Callaway]] <BR>
{{admon/note|"Binary" packages|Throughout this guideline, the term "binary package" refers to the result of building a source package (using rpmbuild or mock, for example) even though it may contain no actual binaries.}}


{{admon/note|"Binary" packages|Throughout this guideline, the term "binary
== Versioning guidelines have moved ==
package" refers to the result of building a source package (using rpmbuild or
This document previously contained information on both naming and versioning.  The versioning guidelines are now at [[Packaging:Versioning]].
mock, for example) even though it may contain no actual binaries.}}


== Common Character Set for Package Naming ==
== Common Character Set for Package Naming ==
Line 22: Line 22:
=== General Naming ===
=== General Naming ===


Package names should be in lower case and use dashes in preference to  
Package names SHOULD be in lower case and use dashes in preference to  
underscores.  You can take some cues from the name of the upstream tarball,  
underscores.  You can take some cues from the name of the upstream tarball,  
the project name from which this software came, and the name which has been used for this  
the project name from which this software came, and the name which has been used for this  
package by other distributions/packagers in the past.  You can also request  
package by other distributions/packagers in the past.  You can also request  
guidance from the upstream developers.  Do not just blindly follow those  
guidance from the upstream developers.  Do not just blindly follow those  
examples, however, as package names should strive to be consistent within  
examples, however, as package names SHOULD strive to be consistent within  
Fedora more than consistent between distributions.
Fedora more than consistent between distributions.


Line 42: Line 42:


=== Separators ===
=== Separators ===
When naming packages for Fedora, the maintainer must use the dash '-' as the delimiter for name parts. The maintainer must NOT use an underscore '_', a plus '+', or a period '.' as a delimiter.  Version numbers used in compat libraries do not need to omit the dot '.' or change it into a dash '-' (see [[#MultiplePackages| Multiple packages with the same base name]] for more info on this case).
When naming packages for Fedora, the maintainer MUST use the dash '-' as the delimiter for name parts. The maintainer MUST NOT use an underscore '_', a plus '+', or a period '.' as a delimiter.  Version numbers used in compat libraries do not need to omit the dot '.' or change it into a dash '-' (see [[#MultiplePackages| Multiple packages with the same base name]] for more info on this case).


There are a few exceptions to the no underscore '_' rule.
There are a few exceptions to the no underscore '_' rule.
Line 66: Line 66:


=== When Upstream Naming is outside of the specified character set ===
=== When Upstream Naming is outside of the specified character set ===
Fedora recognizes that the task of converting text to the specified ASCII character set (aka transliteration) is difficult. Accordingly, when the upstream name is outside of the specified ASCII character set, the Fedora package maintainer should first contact the upstream for that software and ask them for a transliteration of the name for Fedora to use.
Fedora recognizes that the task of converting text to the specified ASCII character set (aka transliteration) is difficult. Accordingly, when the upstream name is outside of the specified ASCII character set, the Fedora package maintainer SHOULD first contact the upstream for that software and ask them for a transliteration of the name for Fedora to use.


If (and only if) the upstream is unable, unwilling, or unavailable to provide a transliterated name, the Fedora packager must choose to either perform their own transliteration, or withdraw the package from consideration in Fedora.
If (and only if) the upstream is unable, unwilling, or unavailable to provide a transliterated name, the Fedora packager must choose to either perform their own transliteration, or withdraw the package from consideration in Fedora.


When deciding how to transliterate a package name, the Fedora packager should look to see what (if any) other distributions have done for that package's name, and take that into account.
When deciding how to transliterate a package name, the Fedora packager SHOULD look to see what (if any) other distributions have done for that package's name, and take that into account.


=== Extra Provides ===
=== Extra Provides ===
Transliterated packages may Provide: the original, non-transliterated name, but are not required to do so.
Transliterated packages MAY Provide: the original, non-transliterated name, but are not required to do so.


== Conflicting Package Names ==
== Conflicting Package Names ==
Line 79: Line 79:


== Multiple packages with the same base name ==
== Multiple packages with the same base name ==
For many reasons, it is sometimes advantageous to keep multiple versions of a package in Fedora to be installed simultaneously. When doing so, the package name should reflect this fact. One package should use the base name with no versions and all other addons should note their version in the name.
For many reasons, it is sometimes advantageous to keep multiple versions of a package in Fedora to be installed simultaneously. When doing so, the package name MUST reflect this fact. One package SHOULD use the base name (with no version information).  All other packages derived from it MUST include the base name suffixed by either:


'''Example:'''
* The package version, which SHOULD include the periods present in the original version.
<BR>The python-sqlalchemy package occasionally has multiple versions in Fedora for backwards compatibility.<BR>
** If the base package name ends with a digit, a single underscore ("_") MUST be appended to the name, and the version MUST be appended to that, in order to avoid confusion over where the name ends and the version begins.
The most current version of python-sqlalchemy has <code>Name: python-sqlalchemy</code> <BR>
** If the base package name does not end with a digit, the version MUST be directly appended to the package name with no intervening separator.
The previous version of python-sqlalchemy has <code>Name: python-sqlalchemy0.5</code> <BR>
* a hyphen ("-") followed by a descriptive suffix such as "stable" which provides some indication as to the nature of the packaged version.  
Removing the dot in the version number may be optionally done and is seen frequently in older packages.  Keeping the dot is preferred in new packages as it is less ambiguous what version foo1.1.6 refers to than foo116.<BR>
Note that we do not use delimiters in the name in this situation.  We attach the version number to the name.


=== Underscores ===
'''Examples:'''
There is one time when a delimiter between a compat package's base name and the version are necessary.  When the compat package's base name ends in a digit the version '''MUST''' be separated from the rest of the package with an underscore.
* The python-sqlalchemy package occasionally has multiple versions in Fedora for backwards compatibility. The most current version of python-sqlalchemy is named <code>python-sqlalchemy</code> and an older supported version is <code>python-sqlalchemy0.5</code>.  No delimiter is used in this situation.
 
* The most current version of the v8 package is named <code>v8</code>.  In order to package version "3.13", the package MUST be named <code>v8_3.13</code>.
'''Example'''
<BR>We want to have a backwards compatible version of the v8 package in Fedora.<BR>
The most current version of v8 has <code>Name: v8</code> <BR>
The previous version of v8 has <code>Name: v8_3.13</code> <BR>
Note that "v8" and "3.13" are separated by an underscore.  This makes the package name much more readable than <code>v83.13</code>.


Please also note that strings such as "-latest" can often become misleading over time if the package (in '''all''' active Fedora releases) is not kept updated with the latest upstream version.


=== Documentation Packages with Embedded OS versioning ===
=== Documentation Packages with Embedded OS versioning ===
Documentation packages (as approved by the Fedora Documentation Project) can be named with the OS version number in the package name to allow parallel installation of multiple versions, in cases where the documentation is specific to a release of Fedora and there is value in having multiple versions simultaneously installed.
Documentation packages (as approved by the Fedora Documentation Project) can be named with the OS version number in the package name to allow parallel installation of multiple versions, in cases where the documentation is specific to a release of Fedora and there is value in having multiple versions simultaneously installed.
== Package Versioning ==
In Fedora we want to ensure that there is always an upgrade path from Fedora release to Fedora release and from Fedora release to the packages in updates.  To do that we need to make sure the packages in the newer Fedora releases have an equal or higher <code>Epoch:Version-Release</code> (EVR) than the ones in older releases.  For example, Fedora-13 ships with <code>foo-1.0-1.fc13</code> and Fedora-14 ships with <code>foo-1.0-2.fc14</code>.  This example shows that the Fedora-14 package will properly upgrade the Fedora-13 package.
A more complex example.  Fedora-13 ships with <code>foo-1.0-1.fc13</code> and Fedora-14 ships with <code>foo-1.0-2.fc14</code>.  Fedora-13 gets an updated foo package: <code>foo-1.0.1-1.fc13</code>.  This update is EVR higher than the package Fedora-13 shipped with so that's good.  However, it is also EVR higher than what Fedora-14 shipped with so we need to make a Fedora-14 update at the same time, likely: <code>foo-1.0.1-1.fc14</code>.  making that update means that someone updating from Fedora-13 with updates enabled will get the correct package on Fedora-14 with updates enabled.
The one time where we temporarily break the upgrade path is from released Fedora to rawhide.  It is allowable to temporarily have a higher EVR in a released Fedora vs rawhide in cases where we need to get a fix out to users of the Fedora releases quickly (for instance, for a security issue) but the fixed package does not currently build in rawhide (for instance, because of a change in a dependent library that requires porting effort).  The changes should be checked into Fedora's SCM for rawhide although there is not yet a build and getting a rawhide build that restores the upgrade path should be a priority.
<code>rpm</code>'s understanding of what package is newer comes from the values of the <code>Epoch</code>, <code>Version</code>, and <code>Release</code> tags.  The next few sections explain what values to use in those tags to ensure that the EVR consistently increases.
=== Version Tag ===
The Version field in the spec is where the maintainer should put the current version of the software being packaged.
If the version is non-numeric (contains tags that are not numbers), you may need to include the additional non-numeric characters in the release field.
There are four cases where the version contains non-numeric characters:
* Pre-release packages: Packages released as "pre-release" versions, prior to a "final" version. Example tags include "alpha", "beta", "rc", "cvs". Unfortunately, we cannot simply put these letters into the version tag, so we use the Release field for this. Details can be found here: [[#NonNumericRelease|  Non-Numeric Version in Release]]
* Post-release packages: Packages released after a "final" version. These packages contain the same numeric version as the "final" version, but have an additional non-numeric identifier. Details can be found here: [[#NonNumericRelease|  Non-Numeric Version in Release]]
* Snapshot packages: Packages built from cvs or subversion snapshots. These packages could be either "pre" or "post" release packages. Details can be found here: [[#NonNumericRelease|  Non-Numeric Version in Release]]
* JPackage derived Fedora packages: Packages which derive from JPackage RPMS follow a special policy. Details can be found here: [[Packaging/JPackagePolicy|JPackagePolicy]]
{{admon/note|Non-use of tilde "~"|rpm-4.10 and above support the Debian-style tilde character which causes a piece of the version to sort before anything else.  At the moment, using this is not permitted for these reasons:
* it is not necessary when the following release tag guidelines are followed properly.
* it is not supported by rpm in currently supported Fedora releases.
* it introduces another special character to achieve something which can be handled in other ways.}}
=== Release Tag ===
The release tag of packages which are not pre- or post-release or snapshots must consist of a positive integer release number and a %{?dist} tag: <code>42%{?dist}</code>.  When a minor change (spec file changed, patch added/removed) occurs, or a package is rebuilt to use newer headers or libraries, the release number is incremented. If a major change (new version of the software being packaged) occurs, the version number is changed to reflect the new software version, and the release number is reset to 1.  It is important to follow these guidelines because automated tools will occasionally be used to increment releases and rebuild packages.
==== Non-Numeric Version in Release ====
There are three cases in which non-numeric versions occur in the Release field:
* Snapshot packages
* Pre-release packages
* Post-release packages
===== Snapshot packages =====
Snapshot packages contain data about where the snapshot came from as well as
ordering information for rpm.  The information about the snapshot will be
called %{checkout} in this section.
%{checkout} consists of the date that the snapshot is made in YYYYMMDD
format, a short (2-5 characters) string identifying the type of revision
control system or that this is a snapshot, and optionally, up to 13
characters (ASCII) alphanumeric characters that could be useful in finding
the revision in the revision control system.
For instance, if you create a snapshot from a git repository on January 2,
2011 with git hash 9e88d7e9efb1bcd5b41a408037bb7cfd47220a64, %{checkout}
string could be any of the following:
<pre>
20110102snap
20110102git
20110102git9e88d7e
</pre>
If the snapshot package is considered a "pre-release package",
follow the guidelines listed in Pre-Release Packages for snapshot packages,
using the %{checkout} that you decide on above.  (For instance, in
kismet-0-0.3.20040204svn, 20040204svn is the %{checkout})
If the snapshot is a "post-release package", follow the
guidelines in the Post-Release Packages section.  Where the %{posttag} in
that section is the %{checkout} string you decided on above.
Example (post-release cvs):
<pre>
kismet-1.0-1%{?dist} (this is the formal release of kismet 1.0)
kismet-1.0-2%{?dist} (this is a bugfix build to the 1.0 release)
kismet-1.0-3.20050515cvs%{?dist} (move to a post-release cvs checkout)
kismet-1.0-4.20050515cvs%{?dist} (bugfix to the post-release cvs checkout)
kismet-1.0-5.20050517cvs%{?dist} (new cvs checkout, note the increment of %{X})
</pre>
===== Pre-Release packages =====
Non-numeric versioned "pre-release" packages can be problematic so they must be treated with care.
These are cases where the upstream "pre-release" version has letters rather than simple numbers in their version.  Often they have tags like alpha, beta, rc, or letters like a and b denoting that it is a version before the "final" number.  Unfortunately, we cannot simply put these letters into the version tag, so we'll use the Release field for this.
Release Tag for Pre-Release Packages:
<code>0.%{X}.%{alphatag}%{?dist}</code>
Where <code>%{X}</code> is the release number increment, and <code>%{alphatag}</code> is the string that came from the version.
In this case, the period '.' is used as the delimiter between the release number increment, and the non-numeric version string. No other extra characters may appear in the Release field. This is to prevent Release values such as "3jpp_2fc.42-spotwashere%{?dist}".
===== Examples =====
{|
|+ '''Example (mozilla pre-release)'''
|-
! Source Archive !! Description
|-
|style=white-space:nowrap| <code>mozilla-1.4a.tar.gz</code> || (this is a pre-release, version 1.4a of mozilla)
|-
| <code>mozilla-1.4.tar.gz</code> || (this is what the 1.4 release will actually look like)
|-
! Release Tag !! Explanation
|-
| <code>mozilla-1.4-0.1.a%{?dist}</code> || (so, this is the acceptable Fedora <code>%{name}-%{version}-%{release}</code>)
|-
| <code>mozilla-1.4-1%{?dist}</code> || (and this is what the 1.4 release Fedora <code>%{name}-%{version}-%{release}</code> should be)
|}
{|
|+ '''Example (alsa-lib pre-release)'''
|-
! Source Archive !! Description
|-
|style=white-space:nowrap| <code>alsa-lib-0.9.2beta1.tar.gz</code> || (this is a beta release of alsa-lib, version 0.9.2beta1)
|-
! Release Tag !! Explanation
|-
| <code>alsa-lib-0.9.2-0.1.beta1%{?dist}</code> || (this is the correct Fedora <code>%{name}-%{version}-%{release}</code>)
|-
| <code>alsa-lib-0.9.2-0.2.beta1%{?dist}</code> || (this is an incremented Fedora <code>%{name}-%{version}-%{release}</code>. Note that the first 0 is not incremented.)
|}
{|
|+ '''Example (kismet pre-release svn checkout)'''
|-
! Release Tag !! Explanation
|-
|style=white-space:nowrap| <code>kismet-0-0.1.20040110svn%{?dist}</code> || (this is a pre-release, svn checkout of kismet)
|-
| <code>kismet-0-0.2.20040110svn%{?dist}</code> || (this is a bugfix to the previous package)
|-
| <code>kismet-0-0.3.20040204svn%{?dist}</code> || (this is a new svn checkout, note the increment of <code>%{X}</code>)
|-
| <code>kismet-1.0-1%{?dist}</code> || (this is the formal release of kismet 1.0)
|}
{|
|+ '''Upgrade Path Example (mozilla)'''
|-
! Release Tag !! Explanation
|-
|style=white-space:nowrap| <code>mozilla-1.4-0.1.a%{?dist}</code> || (this is the Fedora package for 1.4a, as [[#PreReleaseExampleMozilla|above]])
|-
| <code>mozilla-1.4-0.2.a%{?dist}</code> || (this is the first patch on top of 1.4a)
|-
| <code>mozilla-1.4-0.3.a%{?dist}</code> || (this is another new patch on top of 1.4a)
|-
| <code>mozilla-1.4-0.4.b%{?dist}</code> || (this is the first build after upgrade to 1.4b)
|-
| <code>mozilla-1.4-0.5.b%{?dist}</code> || (this is a new patch on top of 1.4b)
|-
| <code>mozilla-1.4-1%{?dist}</code> || (this is after moving to 1.4 "final", and to a normal version)
|-
| <code>mozilla-1.4-2%{?dist}</code> || (this is a new patch on top of 1.4 "final")
|}
{|
|+ '''Upgrade Path Example (alsa-lib)'''
|-
! Release Tag !! Explanation
|-
|style=white-space:nowrap| <code>alsa-lib-0.9.2-0.1.beta1%{?dist}</code> || (this is the Fedora package for 0.9.2beta1, as [[#PreReleaseExampleAlsaLib|above]])
|-
| <code>alsa-lib-0.9.2-0.2.beta1%{?dist}</code> || (this is a new patch on top of 0.9.2beta1)
|-
| <code>alsa-lib-0.9.2-0.3.beta2%{?dist}</code> || (this is after upgrading to 0.9.2beta2)
|-
| <code>alsa-lib-0.9.2-0.4.beta3%{?dist}</code> || (this is after upgrading to 0.9.2beta3)
|-
| <code>alsa-lib-0.9.2-0.5.beta3%{?dist}</code> || (this is a new patch on top of 0.9.2beta3)
|-
| <code>alsa-lib-0.9.2-0.6.rc1%{?dist}</code> || (this is after upgrading to 0.9.2rc1)
|-
| <code>alsa-lib-0.9.2-0.7.rc2%{?dist}</code> || (this is after upgrading to 0.9.2rc2)
|-
| <code>alsa-lib-0.9.2-1%{?dist}</code> || (this is after upgrading to 0.9.2 "final", version becomes normal)
|-
| <code>alsa-lib-0.9.2-2%{?dist}</code> || (this is a new patch on top of 0.9.2 "final")
|}
===== Post-Release packages =====
Like pre-release packages, non-numeric versioned "post-release" packages can be problematic and also must be treated with care. These fall under two generic categories:
* Properly ordered simple versions. These are usually due to quick bugfix releases, such as openssl-0.9.6b  or gkrellm-2.1.7a. As new versions come out, the non-numeric tag is properly incremented (e.g. openssl-0.9.6c) or the numeric version is increased and the non-numeric tag is dropped (openssl-0.9.7). In this case, the non-numeric characters are permitted in the Version: field.
* When upstream uses versions that attempt to have meaning to humans instead of being easy for a computer to order. For example, GA1, CR2, PR3. In this case, the non-numeric string can be put in the Release: field using the following syntax: <code>%{X}.%{posttag}</code>
In this syntax, <code>%{X}</code> is the release number increment, and <code>%{posttag}</code> is the string that came from the version. Here, the period '.' is used as the delimiter between the release number increment and the non-numeric version string. No other extra characters may appear in the Release field.
Example (complicated post-release):
<pre>
foo-1.1.0-0.1.BETA%{?dist} (this is a prerelease, first beta)
foo-1.1.0-0.2.BETA1%{?dist} (this is a prerelease, second beta)
foo-1.1.0-0.3.BETA2%{?dist} (this is a prerelease, third beta)
foo-1.1.0-0.4.CR1%{?dist} (this is a prerelease, candidate release 1)
foo-1.1.0-0.5.CR2%{?dist} (this is a prerelease, candidate release 2)
foo-1.1.0-1%{?dist} (final release)
foo-1.1.0-2.GA1%{?dist} (post release, GA1)
foo-1.1.0-3.CP1%{?dist} (post release, CP1, after GA1)
foo-1.1.0-4.CP2%{?dist} (post release, CP2, after CP1)
foo-1.1.0-5.SP1%{?dist} (post release, SP1, after CP2)
foo-1.1.0-6.SP1_CP1%{?dist} (post release, SP1_CP1, after SP1)
</pre>
It is important to be careful with the post-release scheme, to ensure that package ordering is correct. It may be necessary to use Epoch to ensure that the current package is considered newer than the previous package. In such cases, the packager should try to convince upstream to be more reasonable with their post-release versioning.
Also, packagers using the post-release scheme should put a comment in their spec file with a brief description of the upstream conventions for naming/versioning that are being worked around.
==== The %{?dist} Tag ====
Use of the <code>%{?dist}</code> tag in the Release field is mandatory.
Please refer to the [[Packaging:DistTag]] documentation for the details on the appropriate way to do this.
==== Minor release bumps for old branches ====
Sometimes, you may find yourself in a situation where an older branch needs a fix, but the newer branches are fine. For example, if foo = 1.0-1%{?dist} in F20 and F21, and only F20 needs a fix. Normally, you would need to bump the release in each of the branches to ensure that F20 < F21, but that is a waste of time and energy for the newer branches which do not need to be touched.
In this case, you can add an extra digit (prefixed by a period) to the very end of the release tag in the F20 branch, instead of bumping it the usual way.
Example: <BR>
<pre>
Release: 1%{?dist}
</pre>
<pre>
Release: 1%{?dist}.1
</pre>
This will make a <code>foo-1.0-1.fc20.1</code> package, which is still less than the <code>foo-1.0-1.fc21</code> package in the F21 branch.
As necessary, the last digit (the minor release bump) can be incremented on a per-branch basis as needed.  However, this must never be used in rawhide, because it is always unnecessary there.  Simply increment the appropriate portion of Release: in rawhide.
'''BE CAREFUL WITH THIS!''' You always want to make sure that packages in branches can be upgraded to packages in more recent branches. Or to put it simply, F20< FC21 < F22. There is a tool in the rpmdevtools package called <code>rpmdev-vercmp</code>. This tool will prompt you for two sets of Epoch, Version, and Release, then tell you which is considered newer by rpm.


== Case Sensitivity ==
== Case Sensitivity ==
In Fedora packaging, the maintainer should use his/her best judgement when considering how to name the package. While case sensitivity is not a mandatory requirement, case should only be used where necessary. Keep in mind to respect the wishes of the upstream maintainers. If they refer to their application as "ORBit", you should use "ORBit" as the package name, and not "orbit". However, if they do not express any preference of case, you should default to lowercase naming.<BR>
In Fedora packaging, the maintainer uses their best judgement when considering how to name the package. While case sensitivity is not a mandatory requirement, case SHOULD only be used where necessary. Keep in mind to respect the wishes of the upstream maintainers. If they refer to their application as "ORBit", you SHOULD use "ORBit" as the package name, and not "orbit". However, if they do not express any preference of case, you SHOULD default to lowercase naming.<BR>
<BR>
<BR>
The exception to this is for perl module packaging. The CPAN Group and Type should be capitalized in the name, as if they were proper nouns . (Refer to '''[[#AddonPerl|  Addon Packages (perl modules)]] ''' for details.)
The exception to this is for perl module packaging. The CPAN Group and Type SHOULD be capitalized in the name, as if they were proper nouns . (Refer to '''[[#AddonPerl|  Addon Packages (perl modules)]] ''' for details.)


== Renaming/replacing existing packages ==
== Renaming/replacing existing packages ==
See: [[Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages]]
See: [[Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages]]


== Documentation SubPackages ==
== Documentation Subpackages ==
Large documentation files should go in a subpackage. This subpackage must be named with the format: <code>%{name}-doc</code> .
Large documentation files SHOULD go in a subpackage. This subpackage must be named with the format: <code>%{name}-doc</code> .
The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity.
The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity of files.


== Font Packages ==
== Font Packages ==
Packages containing fonts must be named '''[foundryname-]projectname[-fontfamilyname]-fonts''', in lowercase. For a full explanation, see [[Packaging/FontsPolicy#Naming]].
Packages containing fonts must be named '''[foundryname-]projectname[-fontfamilyname]-fonts''', in lowercase. For a full explanation, see [[Packaging/FontsPolicy#Naming]].


== Addon Packages (General) ==
== Addon Packages ==
If a new package is considered an "addon" package that enhances or adds a new functionality to an existing Fedora package without being useful on its own, its name should reflect this fact.<BR>
If a package is considered an "addon" package that enhances or adds functionality to an existing Fedora package without being useful on its own, its name SHOULD reflect this fact.<BR>
<BR>
<BR>
The new package ("child") should prepend the "parent" package in its name, in the format: <code>%{parent}-%{child}</code>.
The new package ("child") SHOULD prepend the "parent" package in its name, in the format: <code>%{parent}-%{child}</code>.


'''Examples:'''
'''Examples:'''
Line 369: Line 127:
There are some exceptions to this general addon package naming policy, and they are noted below.<BR>
There are some exceptions to this general addon package naming policy, and they are noted below.<BR>


== Addon Packages (httpd, pam, and SDL) ==
=== httpd, pam, and SDL ===
Packages that rely on Apache httpd, pam, or SDL as a parent use a slightly different naming scheme.
Packages that rely on Apache httpd, pam, or SDL as a parent use a slightly different naming scheme.
pam and SDL addons use the format: <code>%{parent}_%{child}</code>, with an underscore "_" as a delimiter.
pam and SDL addons use the format: <code>%{parent}_%{child}</code>, with an underscore "_" as a delimiter.
Line 383: Line 141:
</pre>
</pre>


== Addon Packages (Eclipse plugins) ==
=== Eclipse plugins ===
Eclipse plugin packages MUST be named <code>eclipse-<projectname></code>. For example, a package of the AnyEdit plugin for Eclipse would be named <code>eclipse-anyedit</code>.
Eclipse plugin packages MUST be named <code>eclipse-<projectname></code>. For example, a package of the AnyEdit plugin for Eclipse would be named <code>eclipse-anyedit</code>.


== Addon Packages (emacs components) ==
=== emacs components ===
Packages of emacs add-on components (code that adds additional functionality to emacs compatible editors) have their own naming
Packages of emacs add-on components (code that adds additional functionality to emacs compatible editors) have their own naming
scheme. It is often the case that a component will add functionality to several different compatible editors, such as GNU
scheme. It is often the case that a component will add functionality to several different compatible editors, such as GNU
Emacs and XEmacs (and possibly development versions of these editors). The package name should take into account the upstream name of the
Emacs and XEmacs (and possibly development versions of these editors). The package name SHOULD take into account the upstream name of the
emacs component.
emacs component.


Where a component adds functionality to more than one emacs compatible editor, the package name should be of the form emacs-common-$NAME. In this
Where a component adds functionality to more than one emacs compatible editor, the package name SHOULD be of the form emacs-common-$NAME. In this
case, the main package should contain only files common to all emacs compatible editors, and the code specific to each should be placed in a
case, the main package SHOULD contain only files common to all emacs compatible editors, and the code specific to each SHOULD be placed in a
subpackage reflecting the specific editor $EDITOR-$NAME eg. xemacs-$NAME, emacs-$NAME (the latter being the package specific to GNU Emacs). An
subpackage reflecting the specific editor $EDITOR-$NAME eg. xemacs-$NAME, emacs-$NAME (the latter being the package specific to GNU Emacs). An
example of this scheme can be found in the package emacs-common-muse.
example of this scheme can be found in the package emacs-common-muse.


Where a component is designed to add functionality to only a single emacs compatible editor, the main package name should reflect this by being
Where a component is designed to add functionality to only a single emacs compatible editor, the main package name SHOULD reflect this by being
called $EDITOR-$NAME. An example of this situation can be found in the package emacs-auctex, which is built only for GNU Emacs.
called $EDITOR-$NAME. An example of this situation can be found in the package emacs-auctex, which is built only for GNU Emacs.


Line 408: Line 166:
</pre>
</pre>


== Addon Packages (erlang modules) ==
=== erlang modules ===
Packages of erlang modules (thus they rely on erlang as a parent) have their own naming scheme. They should take into account the upstream name of the erlang module. This makes a package name format of <code>erlang-$NAME</code>. When in doubt, use the name of the module that you use when importing it into a script.
Packages of erlang modules (thus they rely on erlang as a parent) have their own naming scheme. They SHOULD take into account the upstream name of the erlang module. This makes a package name format of <code>erlang-$NAME</code>. When in doubt, use the name of the module that you use when importing it into a script.


'''Example: '''
'''Example: '''
Line 416: Line 174:
</pre>
</pre>


== Addon Packages (gnome shell extensions) ==
=== GAP ===
Packages that extend gnome shell should begin with the prefix <code>gnome-shell-extension-</code>.  In particular, this prefix should not be pluralized (ie: it should '''not''' be <code>gnome-shell-extensions</code>).
See the [[Packaging:GAP#Naming|GAP guidelines]] for the proper naming of GAP addon packages.
 
=== gnome shell extensions ===
Packages that extend gnome shell SHOULD begin with the prefix <code>gnome-shell-extension-</code>.  In particular, this prefix SHOULD NOT be pluralized (ie: it SHOULD NOT be <code>gnome-shell-extensions</code>).


== Addon Packages (OCaml modules) ==
=== OCaml modules ===
OCaml modules, libraries and syntax extensions should be named ocaml-foo.  Examples include: ocaml-extlib, ocaml-ssl.
OCaml modules, libraries and syntax extensions SHOULD be named ocaml-foo.  Examples include: ocaml-extlib, ocaml-ssl.


This naming does not apply to applications written in OCaml, which can be given their normal name.  Examples include: mldonkey, virt-top, cduce.
This naming does not apply to applications written in OCaml, which can be given their normal name.  Examples include: mldonkey, virt-top, cduce.


== Addon Packages (LibreOffice extensions) ==
=== LibreOffice extensions ===
Packages of LibreOffice extensions (thus they rely on LibreOffice as a parent) have their own naming scheme. They must take into account the upstream name of the LibreOffice extension. This makes a package name format of <code>libreoffice-$NAME</code>.
Packages of LibreOffice extensions (thus they rely on LibreOffice as a parent) have their own naming scheme. They must take into account the upstream name of the LibreOffice extension. This makes a package name format of <code>libreoffice-$NAME</code>.




== Addon Packages (perl modules) ==
=== perl modules ===
Packages of perl modules (thus they rely on perl as a parent) use a slightly different naming scheme. They should be named perl-CPANDIST where CPANDIST is the name of the packaged CPAN module distribution (which is almost always also the unit of perl module packaging).  In the rare cases when a CPAN module distribution needs to be split into smaller subpackages eg. due to dependencies, the extra subpackages should be named perl-CPANDIST-Something.<BR>
Packages of perl modules (thus they rely on perl as a parent) use a slightly different naming scheme. They SHOULD be named perl-CPANDIST where CPANDIST is the name of the packaged CPAN module distribution (which is almost always also the unit of perl module packaging).  In the rare cases when a CPAN module distribution needs to be split into smaller subpackages eg. due to dependencies, the extra subpackages SHOULD be named perl-CPANDIST-Something.<BR>


'''Examples: '''
'''Examples: '''
Line 437: Line 198:
</pre>
</pre>


== Addon Packages (php modules) ==
=== php modules ===
For details on the PHP naming scheme, see [[Packaging/PHP#NamingScheme]] .
For details on the PHP naming scheme, see [[Packaging/PHP#NamingScheme]] .


== Addon Packages (Python modules) ==
=== Python modules ===
Python packaging is complicated by the fact that there are two partially incompatible
Python packaging is complicated by the fact that there are two partially incompatible
language versions in use, here called Python2 and Python3.  However, the
language versions in use, here called Python2 and Python3.  However, the
Line 447: Line 208:
does not generally produce a binary package of the same name.
does not generally produce a binary package of the same name.


The package name should reflect the upstream name of the Python module, and
The package name SHOULD reflect the upstream name of the Python module, and
should generally take into account the name of the module used when importing
SHOULD generally take into account the name of the module used when importing
it in Python scripts.  This name will be prefixed depending on the type of the package.
it in Python scripts.  This name will be prefixed depending on the type of the package.


Line 455: Line 216:


=== Python source package naming ===
=== Python source package naming ===
Source packages for Python modules should be named using the <code>python-</code> prefix.
Source packages for Python modules SHOULD be named using the <code>python-</code> prefix.


'''Examples: '''
'''Examples: '''
Line 465: Line 226:
However, it does occur that two separately maintained modules have the same
However, it does occur that two separately maintained modules have the same
name but are targeted against different versions of Python.  In this case,
name but are targeted against different versions of Python.  In this case,
source package for the software targeted at Python2 should take a
source package for the software targeted at Python2 SHOULD take a
<code>python2-</code> prefix, and the source package for the Python3 version
<code>python2-</code> prefix, and the source package for the Python3 version
should have a name beginning with <code>python3-</code>.
SHOULD have a name beginning with <code>python3-</code>.
 
=== Python2 binary package naming ===
Python2 binary packages should be named using a <code>python2-</code> prefix.
 
=== Python3 binary package naming ===
Python3 binary packages shoud be named with a prefix of <code>python3-</code>.
 
=== Outdated Python package naming conventions ===
Previously there were two other conventions for Python package naming, and some
packages using these naming rules persist in Fedora.
 
* Python2 module packages were named using a <code>python-</code> prefix.


* Python module packages with names containing "py" were not required to use any prefix.
==== Python2 binary package naming ====
Python2 binary packages MUST be named using a <code>python2-</code> prefix.


Neither of these may be used for new Python packages.
==== Python3 binary package naming ====
Python3 binary packages MUST be named with a prefix of <code>python3-</code>.


== Addon Packages (R modules) ==
=== R modules ===
Packages of R modules (thus they rely on R as a parent) have their own naming scheme. They should take into account the upstream name of the R module. This makes a package name format of <code>R-$NAME</code>. When in doubt, use the name of the module that you type to import it in R.
Packages of R modules (thus they rely on R as a parent) have their own naming scheme. They SHOULD take into account the upstream name of the R module. This makes a package name format of <code>R-$NAME</code>. When in doubt, use the name of the module that you type to import it in R.


'''Examples: '''
'''Examples: '''
Line 495: Line 246:
</pre>
</pre>


== Addon Packages (Sugar Activities) ==
=== Sugar Activities ===
The name for all packaged Sugar activities must be prefixed with sugar-. For more details, see [[Packaging/SugarActivityGuidelines]] .
The name for all packaged Sugar activities must be prefixed with sugar-. For more details, see [[Packaging/SugarActivityGuidelines]] .


== Addon Packages (Tcl/Tk extensions) ==
=== Tcl/Tk extensions ===
The name for all packaged Tcl/Tk extensions must be prefixed with tcl-. This rule applies even for Tcl/Tk packages that are already prefixed with tcl in the name. For more details, see [[Packaging/Tcl#NamingConventions]].
The name for all packaged Tcl/Tk extensions must be prefixed with tcl-. This rule applies even for Tcl/Tk packages that are already prefixed with tcl in the name. For more details, see [[Packaging/Tcl#NamingConventions]].


== Addon Packages (locales) ==
=== locales ===
If a package adds a locale to an existing parent package, then it can use an underscore in the locale.
If a package adds a locale to an existing parent package, then it can use an underscore in the locale.


Line 510: Line 261:
</pre>
</pre>


== Addon Packages (TeX) ==
=== TeX ===
As Fedora has switched TeX environments in the past, TeX packages should not
As Fedora has switched TeX environments in the past, TeX packages SHOULD not
be named after the TeX environment (TeX Live or teTeX) but instead should
be named after the TeX environment (TeX Live or teTeX) but instead SHOULD
carry the prefix "tex-".
carry the prefix "tex-".
== Authorship ==
The original author of these guidelines was [[TomCallaway|Tom 'spot' Callaway]].  They are now maintained by the [[Packaging_Committee|Packaging Committee]] with input from the Fedora community.


[[Category:Packaging_guidelines]]
[[Category:Packaging_guidelines]]

Revision as of 16:56, 19 July 2018

Note.png
"Binary" packages
Throughout this guideline, the term "binary package" refers to the result of building a source package (using rpmbuild or mock, for example) even though it may contain no actual binaries.

Versioning guidelines have moved

This document previously contained information on both naming and versioning. The versioning guidelines are now at Packaging:Versioning.

Common Character Set for Package Naming

While Fedora is an international community, for consistency and usability, there needs to be a common character set for package naming.

Specifically, all Fedora packages must be named using only the following ASCII characters. These characters are displayed here:

abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789-._+

But do check #Separators for additional restrictions on using the -._+ characters.

General Naming

Package names SHOULD be in lower case and use dashes in preference to underscores. You can take some cues from the name of the upstream tarball, the project name from which this software came, and the name which has been used for this package by other distributions/packagers in the past. You can also request guidance from the upstream developers. Do not just blindly follow those examples, however, as package names SHOULD strive to be consistent within Fedora more than consistent between distributions.

Additionally, it is possible that the upstream name does not fall into the Common Character Set . If this is the case, refer to: When Upstream Naming is outside of the specified character set .

Also remember to check whether the type of package you are packaging has specific rules for naming. Font packages and the various sorts of addon packages, for instance.

Separators

When naming packages for Fedora, the maintainer MUST use the dash '-' as the delimiter for name parts. The maintainer MUST NOT use an underscore '_', a plus '+', or a period '.' as a delimiter. Version numbers used in compat libraries do not need to omit the dot '.' or change it into a dash '-' (see Multiple packages with the same base name for more info on this case).

There are a few exceptions to the no underscore '_' rule.

arptables_jf
dhcpv6_client
java_cup
knm_new
libart_lgpl
lm_sensors
microcode_ctl
nss_db
nss_ldap
sg3_utils
tcp_wrappers

If in doubt, ask on devel@lists.fedoraproject.org.

When Upstream Naming is outside of the specified character set

Fedora recognizes that the task of converting text to the specified ASCII character set (aka transliteration) is difficult. Accordingly, when the upstream name is outside of the specified ASCII character set, the Fedora package maintainer SHOULD first contact the upstream for that software and ask them for a transliteration of the name for Fedora to use.

If (and only if) the upstream is unable, unwilling, or unavailable to provide a transliterated name, the Fedora packager must choose to either perform their own transliteration, or withdraw the package from consideration in Fedora.

When deciding how to transliterate a package name, the Fedora packager SHOULD look to see what (if any) other distributions have done for that package's name, and take that into account.

Extra Provides

Transliterated packages MAY Provide: the original, non-transliterated name, but are not required to do so.

Conflicting Package Names

Conflicting package names, even if they differ by case alone, are not allowed. Please see Packaging:Conflicts#Conflicting Package Names for more details.

Multiple packages with the same base name

For many reasons, it is sometimes advantageous to keep multiple versions of a package in Fedora to be installed simultaneously. When doing so, the package name MUST reflect this fact. One package SHOULD use the base name (with no version information). All other packages derived from it MUST include the base name suffixed by either:

  • The package version, which SHOULD include the periods present in the original version.
    • If the base package name ends with a digit, a single underscore ("_") MUST be appended to the name, and the version MUST be appended to that, in order to avoid confusion over where the name ends and the version begins.
    • If the base package name does not end with a digit, the version MUST be directly appended to the package name with no intervening separator.
  • a hyphen ("-") followed by a descriptive suffix such as "stable" which provides some indication as to the nature of the packaged version.

Examples:

  • The python-sqlalchemy package occasionally has multiple versions in Fedora for backwards compatibility. The most current version of python-sqlalchemy is named python-sqlalchemy and an older supported version is python-sqlalchemy0.5. No delimiter is used in this situation.
  • The most current version of the v8 package is named v8. In order to package version "3.13", the package MUST be named v8_3.13.

Please also note that strings such as "-latest" can often become misleading over time if the package (in all active Fedora releases) is not kept updated with the latest upstream version.

Documentation Packages with Embedded OS versioning

Documentation packages (as approved by the Fedora Documentation Project) can be named with the OS version number in the package name to allow parallel installation of multiple versions, in cases where the documentation is specific to a release of Fedora and there is value in having multiple versions simultaneously installed.

Case Sensitivity

In Fedora packaging, the maintainer uses their best judgement when considering how to name the package. While case sensitivity is not a mandatory requirement, case SHOULD only be used where necessary. Keep in mind to respect the wishes of the upstream maintainers. If they refer to their application as "ORBit", you SHOULD use "ORBit" as the package name, and not "orbit". However, if they do not express any preference of case, you SHOULD default to lowercase naming.

The exception to this is for perl module packaging. The CPAN Group and Type SHOULD be capitalized in the name, as if they were proper nouns . (Refer to Addon Packages (perl modules) for details.)

Renaming/replacing existing packages

See: Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

Documentation Subpackages

Large documentation files SHOULD go in a subpackage. This subpackage must be named with the format: %{name}-doc . The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity of files.

Font Packages

Packages containing fonts must be named [foundryname-]projectname[-fontfamilyname]-fonts, in lowercase. For a full explanation, see Packaging/FontsPolicy#Naming.

Addon Packages

If a package is considered an "addon" package that enhances or adds functionality to an existing Fedora package without being useful on its own, its name SHOULD reflect this fact.

The new package ("child") SHOULD prepend the "parent" package in its name, in the format: %{parent}-%{child}.

Examples:

gnome-applet-netmon (netmon applet for gnome, relies on gnome)
php-adodb (adodb functionality for php, relies on php)
python3-twisted (the twisted module for python3, relies on python3)
xmms-cdread (direct cd read functionality for xmms, relies on xmms)

When the addon package is a language binding, note that the language itself is always the parent. Thus, a lua binding for the "randomdb" database would be lua-randomdb, not randomdb-lua. Also note that some packages may have grandfathered names using the opposite ordering.

There are some exceptions to this general addon package naming policy, and they are noted below.

httpd, pam, and SDL

Packages that rely on Apache httpd, pam, or SDL as a parent use a slightly different naming scheme. pam and SDL addons use the format: %{parent}_%{child}, with an underscore "_" as a delimiter. Apache httpd addons use the format: mod_%{child}, with an underscore "_" as a delimiter. This naming scheme is usually the same as used for the source tarball name.

Examples:

mod_perl (perl components for Apache httpd, relies on httpd)
pam_krb5 (krb5 components for pam, relies on pam)
SDL_gfx (Additional graphics components for SDL, relies on SDL)
SDL_ttf (TrueType font rendering support for SDL, relies on SDL)

Eclipse plugins

Eclipse plugin packages MUST be named eclipse-<projectname>. For example, a package of the AnyEdit plugin for Eclipse would be named eclipse-anyedit.

emacs components

Packages of emacs add-on components (code that adds additional functionality to emacs compatible editors) have their own naming scheme. It is often the case that a component will add functionality to several different compatible editors, such as GNU Emacs and XEmacs (and possibly development versions of these editors). The package name SHOULD take into account the upstream name of the emacs component.

Where a component adds functionality to more than one emacs compatible editor, the package name SHOULD be of the form emacs-common-$NAME. In this case, the main package SHOULD contain only files common to all emacs compatible editors, and the code specific to each SHOULD be placed in a subpackage reflecting the specific editor $EDITOR-$NAME eg. xemacs-$NAME, emacs-$NAME (the latter being the package specific to GNU Emacs). An example of this scheme can be found in the package emacs-common-muse.

Where a component is designed to add functionality to only a single emacs compatible editor, the main package name SHOULD reflect this by being called $EDITOR-$NAME. An example of this situation can be found in the package emacs-auctex, which is built only for GNU Emacs.


Examples:

emacs-common-muse (muse component for all emacs compatible editors)
xemacs-muse (muse component subpackage that provides XEmacs specific files)
emacs-autex (autex component only for GNU Emacs)

erlang modules

Packages of erlang modules (thus they rely on erlang as a parent) have their own naming scheme. They SHOULD take into account the upstream name of the erlang module. This makes a package name format of erlang-$NAME. When in doubt, use the name of the module that you use when importing it into a script.

Example:

erlang-esdl (erlang module named esdl)

GAP

See the GAP guidelines for the proper naming of GAP addon packages.

gnome shell extensions

Packages that extend gnome shell SHOULD begin with the prefix gnome-shell-extension-. In particular, this prefix SHOULD NOT be pluralized (ie: it SHOULD NOT be gnome-shell-extensions).

OCaml modules

OCaml modules, libraries and syntax extensions SHOULD be named ocaml-foo. Examples include: ocaml-extlib, ocaml-ssl.

This naming does not apply to applications written in OCaml, which can be given their normal name. Examples include: mldonkey, virt-top, cduce.

LibreOffice extensions

Packages of LibreOffice extensions (thus they rely on LibreOffice as a parent) have their own naming scheme. They must take into account the upstream name of the LibreOffice extension. This makes a package name format of libreoffice-$NAME.


perl modules

Packages of perl modules (thus they rely on perl as a parent) use a slightly different naming scheme. They SHOULD be named perl-CPANDIST where CPANDIST is the name of the packaged CPAN module distribution (which is almost always also the unit of perl module packaging). In the rare cases when a CPAN module distribution needs to be split into smaller subpackages eg. due to dependencies, the extra subpackages SHOULD be named perl-CPANDIST-Something.

Examples:

perl-Archive-Zip (Archive-Zip is the CPAN distribution name)
perl-Cache-Cache (Cache-Cache is the CPAN distribution name)

php modules

For details on the PHP naming scheme, see Packaging/PHP#NamingScheme .

Python modules

Python packaging is complicated by the fact that there are two partially incompatible language versions in use, here called Python2 and Python3. However, the common case is for one source package to produce a binary package for each Python version, and this results in a naming convention where the source package does not generally produce a binary package of the same name.

The package name SHOULD reflect the upstream name of the Python module, and SHOULD generally take into account the name of the module used when importing it in Python scripts. This name will be prefixed depending on the type of the package.

Note that when a module that has a dot in its name, the usual rule about changing "." to "-" applies.

Python source package naming

Source packages for Python modules SHOULD be named using the python- prefix.

Examples:

python-psycopg  (python module named psycopg)
python-PyQt4 (python module named PyQt4)

However, it does occur that two separately maintained modules have the same name but are targeted against different versions of Python. In this case, source package for the software targeted at Python2 SHOULD take a python2- prefix, and the source package for the Python3 version SHOULD have a name beginning with python3-.

Python2 binary package naming

Python2 binary packages MUST be named using a python2- prefix.

Python3 binary package naming

Python3 binary packages MUST be named with a prefix of python3-.

R modules

Packages of R modules (thus they rely on R as a parent) have their own naming scheme. They SHOULD take into account the upstream name of the R module. This makes a package name format of R-$NAME. When in doubt, use the name of the module that you type to import it in R.

Examples:

R-mAr (R module named mAr)
R-RScaLAPACK (R module named RScaLAPACK)
R-waveslim (R module named waveslim)

Sugar Activities

The name for all packaged Sugar activities must be prefixed with sugar-. For more details, see Packaging/SugarActivityGuidelines .

Tcl/Tk extensions

The name for all packaged Tcl/Tk extensions must be prefixed with tcl-. This rule applies even for Tcl/Tk packages that are already prefixed with tcl in the name. For more details, see Packaging/Tcl#NamingConventions.

locales

If a package adds a locale to an existing parent package, then it can use an underscore in the locale.

Examples:

ttfonts-zh_TW (adds zh_TW locale fonts in ttfonts family)
ttfonts-zh_CN (adds zh_CN locale fonts in ttfonts family)

TeX

As Fedora has switched TeX environments in the past, TeX packages SHOULD not be named after the TeX environment (TeX Live or teTeX) but instead SHOULD carry the prefix "tex-".

Authorship

The original author of these guidelines was Tom 'spot' Callaway. They are now maintained by the Packaging Committee with input from the Fedora community.