[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Warren's Package Naming Proposal - Revision 1



http://www.fedora.us/wiki/PackageNamingGuidelines
The following is based upon current fedora.us package naming guidelines, quickly edited and dramatically simplified because fedora.redhat.com no longer needs many of fedora.us special considerations.


The below proposal is ALMOST EXACTLY THE SAME as fedora.us current scheme except with the leading "0.fdr." removed from all %{release} tags. I would assert that fedora.us package naming scheme has demonstrated to be a great success, thus it should continued in fedora.redhat.com. The below scheme is also in-line with the common practices used by most of Red Hat's existing packages.

This proposal is missing considerations for 3rd party repositories. Theoretically 3rd party repositories should no longer have a reason to publish the same %{name} of any packages that exist in FC or FE because changes should be incorporated upstream. There are however some cases like kde-redhat where this is not possible, so we really need to discuss possible solutions to this. Earlier we had discussed the possibility of simply adding a %{reptag} to the far right of %{release}.



Fedora Package Naming Guidelines
Warren's Proposal for fedora.redhat.com
Revision 1
================================
i. Introduction
   Goals for package naming guidelines
ii. Terminology
A. Package Name
B. Version
C. Release Tag
    1. Release Prefix
    2. Vepoch
    3. Non-Numeric Version to Release
    4. Dist tag
    5. Special: Kernel modules
    6. Special: Plugin, theme etc packages
    7. Special: Minor Number

i. Introduction
===============
Goals for the Fedora Package Naming Guidelines
* Easily understandable package naming policy
* Indication of the original source version (end-user convenience)
* Allow for a smooth upgrade path between multiple levels of testing
branches and future distribution upgrades.  This means E-V-R must never
be exactly identical between distribution versions.
* Minimize the chance of package conflicts for future Fedora
distribution upgrades.

ii. Terminology
==============
name
This is the "Name" field of RPM .spec files.

version
This is the "Version" field of RPM .spec files.

release tag
This is the "Release" field of RPM .spec files.

dist tag
This is a distribution tag indicating which RHL/FC distribution this
package is intended for.  This only occurs in cases where packages from
different distributions are built from the same SRPM and patchlevel.

vepoch
This is our term for "version specific epoch", used in all packages as a simple means of ensuring upgrades by simple incrementing the leading number within the release tag. vepoch is otherwise known as "release number" or "patchlevel". Read C-2 for more information.


E-V-R
Abbreviation for epoch, version, and release.  This is often referred to
when talking about potential package upgrading problems.

A. Package Name
===============
Package name should preferably match the upstream tarball or project
name from which this software came.  In some cases this naming choice is
more complicated.  If this package has been packaged by other
distributions/packagers (Mandrake, SuSE, Conectiva, PLD, PLF, FreshRPMS,
etc.) in the past, then we 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.

Ultimately it is up to QA to decide upon the proper %{name} before publication.

B. Version
==========
If the version is only numbers, then these numbers can be put into the
"version" field of the RPM .spec unchanged.  If the version contains
non-numeric characters, this creates several problems for RPM version
comparison and a broken upgrade path.

Example:
foobar-1.2.3beta1.tar.gz
foobar-1.2.3.tar.gz

While the "1.2.3" version is newer than the 1.2.3beta1 version, RPM
version comparison thinks the former is newer.

Example:
foobar-1.0a
foobar-1.0b

The "1.0b" version is higher than "1.0a", but all versions of RPM prior
to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever
package is first in the comparison "wins", thus this becomes a two way
upgrade problem. This a < b comparison works properly only in RH9 and higher.


For simplicity, Fedora treats both pre-release and post-release
non-numeric version cases the same, making the version purely numeric
and moving the alphabetic part to the release tag.  Take the numeric
portion of the source version and make that the package version tag.

Read C-3 for more details.


C. Release Tag ============== The release tag of Fedora packages more complicated, so this is split into several parts.

C-1. Release Prefix
-------------------
No longer needed in fedora.redhat.com.

C-2. Vepoch
-----------
The leftmost leading number within the release tag is the "version specific epoch" or vepoch in Fedora. This number is incremented with every package update. The vepoch is otherwise known as the "release number" or "patchlevel".


The key difference between the concept of "vepoch" and "patch level" is that everything to the right of the vepoch is PURELY INFORMATIONAL. The only time where it matters is to guarantee a different %{release} tag between two distribution versions.

The vepoch is to be respected by Fedora Core/Extras/Alternatives/Legacy as canonical. Package updates in any repository should always check all other official repositories to be sure that the vepoch is always incremented and never matching an existing package.

With most normal packages, vepoch is a single number starting at "1".
Under the (C-3) non-numeric version case it is two numbers starting at
"0.1" with the second number being the number to increment.

Normal Package Example:
     foobar-1.2.3-1.src.rpm compiles to
     foobar-1.2.3-1.i386.rpm

If this package is patched:
     foobar-1.2.3-2.i386.rpm
     foobar-1.2.3-3.i386.rpm


C-3. Non-Numeric Version to Release
-----------------------------------
As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric
versioned packages can be problematic so they must be treated with care. These are cases where the upstream 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 or
after the number. Read section B to understand why we cannot simply put
these letters into the version tag.


Release Tag for Pre-Release Packages:
     0.%{X}.%{alphatag}
Release Tag for Non-Numeric Post-Release Packages:
     %{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that
came from the version.

Example (pre-release):
     mozilla-1.4a.tar.gz   from usptream is lower than
     mozilla-1.4.tar.gz    the later "final" version thus
     mozilla-1.4-0.1.a     Fedora package name

Example (pre-release):
     alsa-lib-0.9.2beta1.tar.gz  becomes
     alsa-lib-0.9.2-0.1.beta1

Example (post-release):
     gkrellm-2.1.7.tar.gz
     gkrellm-2.1.7a.tar.gz       Quick bugfix release after 2.1.7
     gkrellm-2.1.7-1.a

Upgrade Path Example (mozilla):
     mozilla-1.4-0.1.a
         Patched
     mozilla-1.4-0.2.a
         Patched again
     mozilla-1.4-0.3.a
         Move to 1.4b
     mozilla-1.4-0.4.b
         Patched
     mozilla-1.4-0.5.b
         Move to 1.4 "final" version
         Notice that this becomes a normal C-2 case
     mozilla-1.4-1
         Patched
     mozilla-1.4-2

Upgrade Path Example (alsa-lib):
     alsa-lib-0.9.2-0.1.beta1
         Patched
     alsa-lib-0.9.2-0.2.beta1
         Move to beta2
     alsa-lib-0.9.2-0.3.beta2
         Move to beta3 and simultaneously patch
     alsa-lib-0.9.2-0.4.beta3
         Patched again
     alsa-lib-0.9.2-0.5.beta3
         Move to rc1
     alsa-lib-0.9.2-0.6.rc1
         Move to rc2
     alsa-lib-0.9.2-0.7.rc2
         Move to "final"
     alsa-lib-0.9.2-1
         Patched
     alsa-lib-0.9.2-2

C-4. Dist tag
-------------
In cases where the same SRPM and patchlevel is used between two or more
distributions supported by Fedora, a dist tag is appended to the end of
the release tag defined in C-2 and C-3.  The dist tags with the
following examples appear to be only cosmetic, however the a different
E-V-R is needed between distributions to ensure dist upgrading works
fully in all corner cases.

Dist Tag for Normal Packages:
%{X}.%{disttag}
Where %{X} is the vepoch and %{disttag} is a distribution tag from this table:


0.7.3 Red Hat Linux 7.3
0.8   Red Hat Linux 8
0.9   Red Hat Linux 9
1     Fedora Core 1
1.93  Fedora Core 1.93 beta
1.94  Fedora Core 1.94 beta
2     Fedora Core 2 beta

Example:
     foobar-1.2.3-1_0.7.3.i386.rpm
     foobar-1.2.3-1_0.8.i386.rpm
     foobar-1.2.3-1_0.9.i386.rpm
     foobar-1.2.3-1_1.94.i386.rpm
     foobar-1.2.3-1_2.i386.rpm

Upgrade Path Example (FC1 only shown):
     foobar-1.2.3-1_1.i386.rpm
     foobar-1.2.3-2_1.i386.rpm
     foobar-1.2.3-3_1.i386.rpm


Dist Tag for Pre-Release Packages: %{X}.%{alphatag}.%{disttag} Where %{X} is the vepoch, %{alphatag} is the pre-release tag described in C-3, %{disttag} is a distribution tag described above.

Example:
     alsa-lib-0.9.2-0.1.beta1_0.8.i386.rpm
alsa-lib for RH 8.0
     alsa-lib-0.9.2-0.1.beta1_1.i386.rpm
alsa-lib for FC1

Upgrade Path Example (RH 7.3 only shown):
     alsa-lib-0.9.2-0.1.beta1_0.7.3
     alsa-lib-0.9.2-0.2.beta1_0.7.3
     alsa-lib-0.9.2-0.3.beta2_0.7.3
     alsa-lib-0.9.2-0.4.beta3_0.7.3
     alsa-lib-0.9.2-0.5.beta3_0.7.3
     alsa-lib-0.9.2-0.6.rc1_0.7.3
     alsa-lib-0.9.2-0.7.rc2_0.7.3
     alsa-lib-0.9.2-1_0.7.3
     alsa-lib-0.9.2-2_0.7.3

C-5. Special Case: Kernel modules
---------------------------------
This section needs its own discussion due to changed provides within FC1's kernel, and the fact that older distributions are different.


C-6. Plugin, theme etc packages
-------------------------------
Packages that are plugins, themes or the like, ie. enhance other packages must be named <package-to-enhance>-<enhancement>. If the resulting name differs significantly from upstream naming, a
Provides: <upstream-name> = %{epoch}:%{version}-%{release}
must be added. For example:


Upstream package name: modplug-xmms
Fedora package name:   xmms-modplug
Provides:              modplug-xmms = %{epoch}:%{version}-%{release}

C-7. Minor Number
-----------------------
Probably no longer needed at fedora.redhat.com.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]