Package Naming and Versioning Guidelines

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

When naming a package, the name should match the upstream tarball or project name from which this software came. In some cases, this naming choice may be more complicated. If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision.

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 '-'.

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

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.

Example:openssl occasionally has multiple versions in Fedora for backwards compatibility.
The most current version of openssl has Name: openssl
The previous version of openssl has Name: openssl096b
Note that we do not use delimiters in the name in this situation. We attach the version number to the name, optionally removing the dot from the 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.

Spec file name

The spec file should be named using the %{name}.spec scheme. This is to make it easier for people to find the appropriate spec when they install a src.rpm.

Example:

If your package is named foo-1.0.0-1.src.rpm, then the spec file should be named foo.spec.

There is normally no need to include the %{version} in the spec file name. If you are packaging multiple versions of a package for simultaneous use, they should already reflect the version in the %{name}.spec scheme (refer to Multiple Packages with the same base name for details). In normal cases adding the version can cause the spec file's history to be lost when a package's version is upgraded.

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 Epoch:Version-Release (EVR) than the ones in older releases. For example, Fedora-13 ships with foo-1.0-1.fc13 and Fedora-14 ships with foo-1.0-2.fc14. This example shows that the Fedora-14 package will properly upgrade the Fedora-13 package.

A more complex example. Fedora-13 ships with foo-1.0-1.fc13 and Fedora-14 ships with foo-1.0-2.fc14. Fedora-13 gets an updated foo package: foo-1.0.1-1.fc13. 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: foo-1.0.1-1.fc14. 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.

rpm's understanding of what package is newer comes from the values of the Epoch, Version, and Release 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: 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: 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: Non-Numeric Version in Release

JPackage derived Fedora packages: Packages which derive from JPackage RPMS follow a special policy. Details can be found here: JPackagePolicy

Release Tag

In the past, Fedora.us used 0.fdr as a release prefix to identify Fedora.us packages. In Fedora, this repository "tagging" is unnecessary, and should not be used. The release number (referred to in some older documentation as a "vepoch") is how the maintainer marks build revisions, starting from 1. 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 should be incremented. If a major change (new version of the software being packaged) occurs, the version number should be changed to reflect the new software version, and the release number should be reset to 1.

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:

20110102snap
20110102git
20110102git9e88d7e

If the snapshot package is considered a "pre-release package", you should
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", you should 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):

kismet-1.0-1 (this is the formal release of kismet 1.0)
kismet-1.0-2 (this is a bugfix build to the 1.0 release)
kismet-1.0-3.20050515cvs (move to a post-release cvs checkout)
kismet-1.0-4.20050515cvs (bugfix to the post-release cvs checkout)
kismet-1.0-5.20050517cvs (new cvs checkout, note the increment of %{X})

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:
0.%{X}.%{alphatag}

Where %{X} is the release number increment, and %{alphatag} is the string that came from the version.
In this case, the period '.' should be used as the delimiter between the release number increment, and the non-numeric version string. No other extra characters should appear in the Release field. This is to prevent Release values such as "3jpp_2fc.42-spotwashere".

Example (mozilla pre-release)

Source Archive

Description

mozilla-1.4a.tar.gz

(this is a pre-release, version 1.4a of mozilla)

mozilla-1.4.tar.gz

(this is what the 1.4 release will actually look like)

Release Tag

Explanation

mozilla-1.4-0.1.a

(so, this is the acceptable Fedora %{name}-%{version}-%{release})

mozilla-1.4-1

(and this is what the 1.4 release Fedora %{name}-%{version}-%{release} should be)

Example (alsa-lib pre-release)

Source Archive

Description

alsa-lib-0.9.2beta1.tar.gz

(this is a beta release of alsa-lib, version 0.9.2beta1)

Release Tag

Explanation

alsa-lib-0.9.2-0.1.beta1

(this is the correct Fedora %{name}-%{version}-%{release})

alsa-lib-0.9.2-0.2.beta1

(this is an incremented Fedora %{name}-%{version}-%{release}. Note that the first 0 is not incremented.)

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: %{X}.%{posttag}

In this syntax, %{X} is the release number increment, and %{posttag} is the string that came from the version. Here, the period '.' should be used as the delimiter between the release number increment, and the non-numeric version string. No other extra characters should appear in the Release field.

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.

Using the %{?dist} Tag

If you wish to use a single spec file to build for multiple distributions, you can use the %{?dist} tag in the Release field.
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 FC-4 and FC-5, and only FC-4 needs a fix. Normally, you would need to bump the release in each of the branches to ensure that FC-4 < FC-5, 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 FC-4 branch, instead of bumping it the usual way.
Example:

Release: 1%{?dist}

Release: 1%{?dist}.1

This will make a foo-1.0-1.fc4.1 package, which is still less than the foo-1.0-1.fc5 package in the FC-5 branch.

As necessary, the last digit (the minor release bump) can be incremented on a per-branch basis as needed.
This is ONLY permitted if you are using disttags in your Release field.

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, FC-4 < FC-5 < FC-6. There is a tool in the rpmdevtools package called rpmdev-vercmp. This tool will prompt you for two sets of Epoch, Version, and Release, then tell you which is considered newer by rpm.

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.

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

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.

Font Packages

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

Addon Packages (General)

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.

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

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

Addon Packages (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.

Addon Packages (Eclipse plugins)

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

Addon Packages (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.

Addon Packages (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)

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).

Addon Packages (OCaml modules)

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 (OpenOffice.org extensions)

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

Addon Packages (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.

Addon Packages (php modules)

Addon Packages (python modules)

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

There is an exception to this rule. If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable.

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

Addon Packages (python3 modules)

An rpm with a python prefix or suffix means a python2 rpm so we need a different prefix to denote python3 packages. For this, we use python3. We have two constraints that the python2 packages don't operate under:

We need to be clear about these modules being for python3 so we don't have an exception for packages that already have "py" in their names like python2 modules.

Consumers of the packages need to be able to find them even if they don't know whether they're using the python2 or python3 version.

So all python3 modules MUST have python3 in their name. Other than that, the module must be in the same format as the python2 package. Some examples:

Fedora python 2 package

Upstream name

Fedora Python 3 package name

python-lxml

lxml

python3-lxml

pygtk2

pygtk

python3-pygtk

gstreamer-python

gst-python

gstreamer-python3

gnome-python2

gnome-python

gnome-python3

rpm-python

(part of rpm)

rpm-python3

Addon Packages (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.

Addon Packages (Sugar Activities)

Addon Packages (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.

Addon Packages (locales)

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