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.

Quoting Warren Togami <warren(a)togami.com&gt;:
<huge snip>
Looks good to me. The only thing I don't really like at first sight is
separating disttag with underscore rather than something else but then that's
probably just a matter of getting used to :) Oh and it's anyway cleaner looking
than all the .rh9.0.93.foo type of numberings.

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.

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.

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.

I agree, and rpm (and deb for this matter) should be redesigned long
term to have different semantics of a upstream version used for
rpm/deb ordering and one used for the package name. So
foo-1.2.3beta17.8 could be packaged as foo-1.2.3beta17.8-1.rh9, but be
compared as say 1.2.2.99.17.8.
This could be done at the cost of introducing a new tag like
versionsort that defaults to %{version}. When present it would be used
for ordering and interpackage dependencies (Requires, Conflicts,
Obsoletes etc.).
It would make epochs unnecessary and it would be a local (in time)
change of a package (contrasted to epoch's global and eternal presence
...).
This was proposed on the rpm-list ages ago, but died a silent death,
maybe it could be resurrected here?

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

Hmmm, I am in agreement. While we fedora.us people had no problem with
vepoch for many months, I can see where it is confusing. I designed the
name to be "Kind of like epoch, vepoch trumps all, but less."
Perhaps "patchlevel" is a better word.

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

Yes, when I originally designed this method I was pointing at bero's
packages as justification. "See! Look, Red Hat did it!"
Conspiracy theory: Was he canned because of persecution from aberrant
packaging? =)
Ok... bad joke.

>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?

Err... you are completely right about it not being necessary in the
post-release case. I am not sure why our fedora.us policy retained that
even though it was unnecessary for all these months. The way I
understand the older version of rpm broken rpmvercmp behavior, this
wouldn't be a problem with those versions too.

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

Oops. Yeah, fedora.us original plan was ".", however some here on
fedora-devel-list argued toward "_" as a more clear separator between
the patchlevel and disttag because it can be confusing with so many "."
I personally actually prefer the "." separator, but I really don't care
which is chosen.
Warren

> 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)
Oops. Yeah, fedora.us original plan was ".", however some here on
fedora-devel-list argued toward "_" as a more clear separator between
the patchlevel and disttag because it can be confusing with so many "."
I personally actually prefer the "." separator, but I really don't care
which is chosen.

For the record, I think underscores are hideous too.
That makes it three people that commented on this:)
Cheers,
--
Nicolas Mailhot

Le ven 31/10/2003 à 15:31, Warren Togami a écrit :
> Mike A. Harris wrote:
> > 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)
>
> Oops. Yeah, fedora.us original plan was ".", however some here on
> fedora-devel-list argued toward "_" as a more clear separator between
> the patchlevel and disttag because it can be confusing with so many "."
>
> I personally actually prefer the "." separator, but I really don't
care
> which is chosen.
For the record, I think underscores are hideous too.
That makes it three people that commented on this:)

Heh, why not make it @ .. it sorta even has a meaning "foo-1.2.3 at
(==for) RHL 9": foobar-1.2.3-1(a)0.9.i386.rpm. Looks lovely doesn't it :)
<ducks and runs>
- Panu -

>>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?
>
Err... you are completely right about it not being necessary in the
post-release case. I am not sure why our fedora.us policy retained that
even though it was unnecessary for all these months. The way I
understand the older version of rpm broken rpmvercmp behavior, this
wouldn't be a problem with those versions too.

* To be able to go back from 2.1.7a to a patched 2.1.7 in case the
2.1.7a post-release "fix" turns out to cause side-effects.
* Consistency above all.
* The road of least surprise (with regard to upstream versioning).
* To help avoid that users think foo-1.0a would be an unstable alpha
version, when in fact it is a post-release patch-level.
--

On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
>
> Err... you are completely right about it not being necessary in the
> post-release case. I am not sure why our fedora.us policy retained that
> even though it was unnecessary for all these months. The way I
> understand the older version of rpm broken rpmvercmp behavior, this
> wouldn't be a problem with those versions too.
* To be able to go back from 2.1.7a to a patched 2.1.7 in case the
2.1.7a post-release "fix" turns out to cause side-effects.
* Consistency above all.
* The road of least surprise (with regard to upstream versioning).
* To help avoid that users think foo-1.0a would be an unstable alpha
version, when in fact it is a post-release patch-level.

Also, if foo-1.0a < foo-1.0b < foo-1.0a, as presented earlier in the
proposal (the "two-way upgrade problem") exists for prereleases, why
wouldn't it exist for postreleases?

On Fri, 2003-10-31 at 19:00, Michael Schwendt wrote:
> On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
> >
> > Err... you are completely right about it not being necessary in the
> > post-release case. I am not sure why our fedora.us policy retained that
> > even though it was unnecessary for all these months. The way I
> > understand the older version of rpm broken rpmvercmp behavior, this
> > wouldn't be a problem with those versions too.
>
> * To be able to go back from 2.1.7a to a patched 2.1.7 in case the
> 2.1.7a post-release "fix" turns out to cause side-effects.
>
> * Consistency above all.
>
> * The road of least surprise (with regard to upstream versioning).
>
> * To help avoid that users think foo-1.0a would be an unstable alpha
> version, when in fact it is a post-release patch-level.
Also, if foo-1.0a < foo-1.0b < foo-1.0a, as presented earlier in the
proposal (the "two-way upgrade problem") exists for prereleases, why
wouldn't it exist for postreleases?

Actually, the two-way upgrade problem was fixed right before RH9. So
rpm-4.2 in RH9, rpm-4.2.1, rpm-4.1.1, rpm-4.0.5 all behave properly in
this case.
This however does not matter, since it has been agreed upon on
fedora-legacy list that ALL distributions supported by Fedora Legacy
will force an upgrade of rpm as a requirement for users to begin using
those repositories. This is in order to enforce consistency and avoid
old bugs that were fixed ages ago. (A tremendous amount of verification
testing will happen before each rpm is published for Legacy.)
Warren

This however does not matter, since it has been agreed upon on
fedora-legacy list that ALL distributions supported by Fedora Legacy
will force an upgrade of rpm as a requirement for users to begin using
those repositories.

When was this agreed upon?
While I personally support this scheme, I was under the impression
that there were more people against enforcing rpm upgrades for
minimally changes (e.g. fedora-legacy should only provide security
related errata). Especially because RH itself did not issue errata for
rpm despite the known problems.
In fact, Warren, I believe we were the only two supporting rpm
upgrades, so unless we are the only left subscribers of fedora-legacy,
it is not yet an agreement of the whole list. ;)
--
Axel.Thimm(a)physik.fu-berlin.de

While I personally support this scheme, I was under the impression
that there were more people against enforcing rpm upgrades for
minimally changes (e.g. fedora-legacy should only provide security
related errata). Especially because RH itself did not issue errata
for rpm despite the known problems.
In fact, Warren, I believe we were the only two supporting rpm
upgrades, so unless we are the only left subscribers of
fedora-legacy, it is not yet an agreement of the whole list. ;)

On Friday 07 November 2003 08:47, Axel Thimm wrote:
> While I personally support this scheme, I was under the impression
> that there were more people against enforcing rpm upgrades for
> minimally changes (e.g. fedora-legacy should only provide security
> related errata). Especially because RH itself did not issue errata
> for rpm despite the known problems.
>
> In fact, Warren, I believe we were the only two supporting rpm
> upgrades, so unless we are the only left subscribers of
> fedora-legacy, it is not yet an agreement of the whole list. ;)
I personally agreed to it, until somebody showed me clear evidence that
it could/would break something.

I supported it too I wasn't the only one.
Is this "me too thread" really useful ? Did anyone propose an
alternative scheme that had any chance to work ?
Cheers,
--
Nicolas Mailhot

Le ven 07/11/2003 à 17:59, Jesse Keating a écrit :
> On Friday 07 November 2003 08:47, Axel Thimm wrote:
> > While I personally support this scheme, I was under the impression
> > that there were more people against enforcing rpm upgrades for
> > minimally changes (e.g. fedora-legacy should only provide security
> > related errata). Especially because RH itself did not issue errata
> > for rpm despite the known problems.
> >
> > In fact, Warren, I believe we were the only two supporting rpm
> > upgrades, so unless we are the only left subscribers of
> > fedora-legacy, it is not yet an agreement of the whole list. ;)
>
> I personally agreed to it, until somebody showed me clear evidence that
> it could/would break something.
I supported it too I wasn't the only one.
Is this "me too thread" really useful ? Did anyone propose an
alternative scheme that had any chance to work ?

More importantly (IMHO, YMMV): what does that imply, if anything,
related to the naming guidelines?
There was some support for moving/keeping non-numeric upstream
post-release version parts in %{version} instead of moving them into
%{release}, what is the consensus on that now?

> This however does not matter, since it has been agreed upon on
> fedora-legacy list that ALL distributions supported by Fedora Legacy
> will force an upgrade of rpm as a requirement for users to begin using
> those repositories.
When was this agreed upon?
While I personally support this scheme, I was under the impression
that there were more people against enforcing rpm upgrades for
minimally changes (e.g. fedora-legacy should only provide security
related errata). Especially because RH itself did not issue errata for
rpm despite the known problems.
In fact, Warren, I believe we were the only two supporting rpm
upgrades, so unless we are the only left subscribers of fedora-legacy,
it is not yet an agreement of the whole list. ;)

Make it 3 then... I support Warren's suggestion. Perhaps others
will speak up too if it is something up for democratic vote. If
it's not up for democratic vote, hail Warren!
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat

Make it 3 then... I support Warren's suggestion. Perhaps
others
will speak up too if it is something up for democratic vote. If
it's not up for democratic vote, hail Warren!

Well, I think right now I'd have the final say, but I do differ to
warren on a lot of issues. I'd have to dig up some old email, but
there were some locking bugs and upgrade version issues that we wanted
to solve with a single rpm version set across all the supported Legacy
distros. Fedora.us has done a lot of research on it so I've been told,
and they haven't found any reason to not fix these nasty bugs.
So I'm going to be a bit totalitarian for a moment, and unless somebody
can show me a really good reason to _not_ fix RPM across these release,
then rpm will be upgraded.
Note, this is not an upgrade just to upgrade, we're fixing bugs here.
--
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating

Make it 3 then... I support Warren's suggestion. Perhaps
others
will speak up too if it is something up for democratic vote. If
it's not up for democratic vote, hail Warren!

4. I mentioned the fact that Red Hat had already set the precedent back with
some errata packages for RPM with RHL 6.2, 7, and others.
By way of introduction, since everyone else is doing them, my qualifications,
etc, are as follows...
I have maintained the PostgreSQL RPMset since July of 1999, and had my RPM
work includedby Red Hat as part of RHL 6.1. I have built various other RPMs
for my use, and have provided a few for other projects over the years,
including the BibleTime SWORD project KDE reader. I have actively used and
developed on Red Hat Linux since version 4.1 in April 1997. I am one of the
few enterprise users of the Aurora Linux distribution on a network of
UltraSPARCs at PARI. I have operated an internet radio site (on Red Hat
Linux and RealAudio) since May 1997. I have recovered from a root
compromise. I currently maintain the AOLserver PostgreSQL driver.
And I of course try to show the benefits of Linux and open source at every
opportunity to every one.
A couple of things about me that are rather unusual among open source people
is that I am a duly ordained Baptist minister and am a professor at Anchor
Baptist Bible College, teaching English amongst other courses.
--
(Rev.) Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu

On Fri, Nov 07, 2003 at 01:27:20AM -1000, Warren Togami wrote:
> This however does not matter, since it has been agreed upon on
> fedora-legacy list that ALL distributions supported by Fedora Legacy
> will force an upgrade of rpm as a requirement for users to begin using
> those repositories.
When was this agreed upon?
[...] so unless we are the only left subscribers of fedora-legacy,
it is not yet an agreement of the whole list. ;)

Am I the only one that finds it questionable that assertions like
these are simply being made?
Even if the whole list and the world agrees postscriptum (which it
doesn't), what kind of tacticts are these? There was clearly not a
list agreement (set aside if there is need for one), so why present
your opinion as the list's?
Did I mention that it was agreed upon all fedora-lists to remove glibc
from ALL distributions?
--
Axel.Thimm(a)physik.fu-berlin.de

Am I the only one that finds it questionable that assertions like
these are simply being made?
Even if the whole list and the world agrees postscriptum (which it
doesn't), what kind of tacticts are these? There was clearly not a
list agreement (set aside if there is need for one), so why present
your opinion as the list's?
Did I mention that it was agreed upon all fedora-lists to remove glibc
from ALL distributions?

> > Are there cases where rpm would consider imap-2000a as
older than
> > imap-2000?
> >
> > jbj?
> >
>
> Err... you are completely right about it not being necessary in the
> post-release case. I am not sure why our fedora.us policy retained that
> even though it was unnecessary for all these months. The way I
> understand the older version of rpm broken rpmvercmp behavior, this
> wouldn't be a problem with those versions too.
* To be able to go back from 2.1.7a to a patched 2.1.7 in case the
2.1.7a post-release "fix" turns out to cause side-effects.

Hmm I'm not sure if I buy that -- extrapolating form that, one should
also be able to go back from 2.1.8 to 2.1.7 in case the new version
turns out to cause side-effects (without any "--oldpackages" stuff or
that point is moot). We could also set the version to "1" for all
packages and use only serial numbers for releases -- that way updating
always works ;-).
I think the version should always be the upstream version where these
are not incompatible with RPM version comparisons and real version
numbers (and not CVS dates or the like because they may be substituted
with real version numbers which are likley less RPM wise) and (optional)
characters represent newer patch levels (and not prereleases). If that
version number contains dashes, replacing them with underscores might be
necessary.

Care to explain that one? Of course the idea I have about versioning
seems most consistent to me but I'm sure you can shed some light on why
version numbers differing from upstream are more consistent ;-).

* To help avoid that users think foo-1.0a would be an unstable alpha
version, when in fact it is a post-release patch-level.

I do not think that is the purpose of an RPM version tag. It exists so
the user knows that this is the upstream version number-- how else would
a user be able to submit bug reports upstream if he cannot supply the
real version number/string/whatever. If users interpret version strings
like "1.0a" as an alpha version when they're not -- well, that's tough
luck but nothing that should be worked around by some RPM version
trickeries.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

On Fri, 2003-10-31 at 18:00, Michael Schwendt wrote:
> On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
[...]
> > > Are there cases where rpm would consider imap-2000a as older than
> > > imap-2000?
> > >
> > > jbj?
> > >
> >
> > Err... you are completely right about it not being necessary in the
> > post-release case. I am not sure why our fedora.us policy retained that
> > even though it was unnecessary for all these months. The way I
> > understand the older version of rpm broken rpmvercmp behavior, this
> > wouldn't be a problem with those versions too.
>
> * To be able to go back from 2.1.7a to a patched 2.1.7 in case the
> 2.1.7a post-release "fix" turns out to cause side-effects.
Hmm I'm not sure if I buy that -- extrapolating form that, one should
also be able to go back from 2.1.8 to 2.1.7 in case the new version
turns out to cause side-effects (without any "--oldpackages" stuff or
that point is moot).

That would be something different, since I assume 2.1.8 comes quite
some time after 2.1.7. On the contrary, 2.1.7a would be sort of a
quick brown paperbag fix attempt which would be released shortly after
2.1.7, often just a few hours later or on the same day. Including such
an upstream fix prior to publishing a package is tempting, and
sometimes it turns out right after release that the fix breaks other
parts of the software in an unexpected way and the real fix takes more
time.
I'd a fan of serial numbers, but not when they're hidden. I would
even like a scheme like
name.serial.upstreamversion.arch.rpm

I think the version should always be the upstream version where
these
are not incompatible with RPM version comparisons and real version
numbers (and not CVS dates or the like because they may be substituted
with real version numbers which are likley less RPM wise) and (optional)
characters represent newer patch levels (and not prereleases). If that
version number contains dashes, replacing them with underscores might be
necessary.

> * Consistency above all.
Care to explain that one? Of course the idea I have about versioning
seems most consistent to me but I'm sure you can shed some light on why
version numbers differing from upstream are more consistent ;-).

Since you understand the need for a pre-release version/release
modification guideline, you do understand this guideline very well,
too, and hence it doesn't need much of an explanation IMO.

> * The road of least surprise (with regard to upstream
versioning).
That's what I want.
> * To help avoid that users think foo-1.0a would be an unstable alpha
> version, when in fact it is a post-release patch-level.
I do not think that is the purpose of an RPM version tag. It exists so
the user knows that this is the upstream version number-- how else would
a user be able to submit bug reports upstream if he cannot supply the
real version number/string/whatever.

The user should find the software version number in the "About" or
"Help" sections, in the manual and should never rely on package
versioning. E.g. KDE 3.1.4-6 is not an upstream version, GCC 2.96
wasn't either. Now don't tell me all users know what the release
version is. Why should it be allowed (or make sense) to modify
1.0rc3-2 to 1.0-2.rc3, but not 1.0pl1-2 to 1.0-2.pl1?

If users interpret version strings
like "1.0a" as an alpha version when they're not -- well, that's tough
luck but nothing that should be worked around by some RPM version
trickeries.

It's not a primary goal, but it helps. It should not be user's
responsibility to know that Mozilla 1.5a is older than 1.5, but Foo
1.5a is a bug-fix release for Foo 1.5. The package release version
should make that obvious. Else user keeps using the unstable Mozilla
1.5a as long as rpmseek.com doesn't list a newer version.
I don't like the dependency on upstream versioning at all, cases such
as 1.01 > 1.0.2, 0.6 > 0.50, 0.010 > 0.1, 1.2 < 1.02, 1.0a < 1.0 or
1.0a > 1.0, ... not all can be dealt with without modifying these
version numbers.
--

> 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.
Hmmm, I am in agreement. While we fedora.us people had no problem with
vepoch for many months, I can see where it is confusing. I designed the
name to be "Kind of like epoch, vepoch trumps all, but less."
Perhaps "patchlevel" is a better word.

I'm not sure patchlevel gives the right visual either.. It
implies something to do with the number of patches being applied,
or the version of a patch or something.

> 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.
Yes, when I originally designed this method I was pointing at bero's
packages as justification. "See! Look, Red Hat did it!"

Err... you are completely right about it not being necessary in the
post-release case. I am not sure why our fedora.us policy retained that
even though it was unnecessary for all these months. The way I
understand the older version of rpm broken rpmvercmp behavior, this
wouldn't be a problem with those versions too.

Ah. RHL 7.2 shipped with rpm-4.0.3-1.03, and 7.3 shipped with
rpm-4.0.4-7x.18, both of which don't have this problem. rpm
4.0.4 is the current erratum for all distribution releases from
RHL 7.0 and later (or a newer version of rpm). Older versions
aparently did have the problem according to other mails I
received, but I think it's safe to say that distro releases
supported by Fedora are unaffected, and that at least as far
back as a properly updated 7.0 system should also be unaffected.
RHL 6.2 seems to have an older rpm version which may or may not
be affected, but I think that's outside the care zone. ;o)

> 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)
Oops. Yeah, fedora.us original plan was ".", however some here on
fedora-devel-list argued toward "_" as a more clear separator between
the patchlevel and disttag because it can be confusing with so many "."

I personally actually prefer the "." separator, but I really
don't care
which is chosen.

I suppose if it's a useful thing to people that we should keep an
open mind about it, even if it is ugly. ;o)
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat

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.

a < b has worked in RPM from day one. The only issue in rpm's version
comparison function was comparing a letter to a number, for example 1.a
vs 1.1. All versions of rpm would get the example right.
Thanks.
Peter