Warren's Package Naming Proposal - Revision 1
Mike A. Harris
mharris at redhat.com
Fri Oct 31 10:53:58 UTC 2003
On Thu, 30 Oct 2003, Warren Togami wrote:
>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.
Some feedback below...
>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.
The "Epoch" tag is already quite confusing to many/most beginner
and intermediate packagers, perhaps even some advanced packagers.
It's often used when not needed, and with a small amount of
forethought when packaging things can be completely avoided in
many if not all cases where Epoch ends up being used nowadays by
someone.
I think your "vepoch" tag potentially adds confusion between what
Epoch is and what vepoch is. I unfortunately don't have a better
name to offer other than perhaps "versionserial" to indicate a
monotonically increasing serial number tied to a version.
Just a personal opinion that this might confuse people, and if a
better name can be chosen that is short enough and clear, it
might be better.
>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.
Just to contrast, at Red Hat, package naming is usually
determined by the developer who creates a new package from
scratch, or who Red Hattifies an existing src.rpm from the wild.
I do realize though that when you refer to QA above, you don't
mean Red Hat QA, but rather fedora.us QA in sort of a quality
control and semi-standardization sense. Sounds like a good idea
to me. Also a good idea for people to provide feedback as early
on as possible about developer chosen *crappy* package names.
I've seen MySQL in rpm format out there named "mysql", "Mysql",
"MySQL", and MySql". ICK!
>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.
I strongly agree with this approach. Probably because I stole it
from bero, and I think you picked it up from me or from bero
also. ;o) It works very well IMHO. It's also very useful with
CVS based releases where you can embed the CVS date into the
release field instead of the version field, thus avoiding having
to use Epoch later on to override the large integer release
number from a CVS date.
Example:
This: XFree86-4.3.99.15-0.20031030
is better IMHO, than this: XFree86-20031030-1
The latter one, would require an ugly Epoch bump to upgrade to
XFree86 4.4.0 for example. That can be avoided by using the
method you describe. (Which is why my CVS rpm packages tend to
have insanely long version-release tags <grin>)
>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
I find the above quite confusing, and I actually understand what
your vepoch is there for and why. ;o) Might want to try
rewording that perhaps, although I'm not volunteering.... ;o)
>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
For gkrellm is this necessary? rpm considers 2.1.7a newer than
2.1.7 already unless something has changed. Another package of
this nature is UW imap. It is generally released with an integer
based version number of the year of it's release, possibly
followed by a single letter indicating a revision within that
year. ie: imap-2000 imap-2000a imap-2000b
In rpm's normal operation these packages are naturally treated as
the older package on the left, with the newer ones proceeding to
the right.
My personal preference would be to just let rpm assume that as it
should work. I've never gotten bug reports of it not working
anyway. Moving things from the version to the release field
unnecessarily just complicates packaging when there's no real
benefit IMHO. For the pre-release cases above it makes sense as
it's being done in order to override rpm's default behaviour,
which would be to treat what is a final release as older than a
prerelease.
I believe treating both pre-release and post-release in the same
manner just for consistency with both types of lettered versioned
packages is just cosmetic consistency, but doesn't provide any
functional or technical benefit. In other words, sticking with
the upstream version in the version field is IMHO best unless
there is a technical benefit of doing so, such as avoiding having
to later use Epoch to override a prerelease build.
Are there cases where rpm would consider imap-2000a as older than
imap-2000?
jbj?
>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
Ick. Underscores in version/release are hideous IMHO. I'd use
"." instead of "_". Your comment at the top of this section
indicates a ".", so perhaps you just made a typo, and sequence of
cut and paste errors? ;o)
>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.
Bah, who needs kernel modules. ;o)
>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}
I agree, this is a sensible diversion from an upstream package
IMHO.
>C-7. Minor Number
>-----------------------
>Probably no longer needed at fedora.redhat.com.
Change that to read "MBZ, reserved for future" to cover your
bases, and looks good. ;o)
Hope my feedback is useful... if not, feel free to kick me in the
pants. ;o)
Take care,
TTYL
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
More information about the fedora-devel-list
mailing list