Warren's Package Naming Proposal - Revision 1

[Warren Togami]

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.

[Panu Matilainen]

Quoting Warren Togami <***@togami.com>:
<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.

Post by Warren Togami
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.

Hmm, what's changed? Doesn't look that different to me:
Current rawhide kernel:
[***@linox03 RPMS]$ rpm -qp --provides kernel-smp-2.4.22-1.2115.nptl.i686.rpm
kernel = 2.4.22
kernel-drm = 4.1.0
kernel-drm = 4.2.0
kernel-drm = 4.3.0
kernel-smp = 2.4.22-1.2115.nptl

Latest RHL9 errata kernel:
[***@linox03 i686]$ rpm -qp --provides kernel-smp-2.4.20-20.9.i686.rpm
kernel = 2.4.20
kernel-drm = 4.1.0
kernel-drm = 4.2.0
kernel-drm = 4.2.99.3
kernel-drm = 4.3.0
module-info
kernel-smp = 2.4.20-20.9

The only change is the dropped module-info provides but that wasn't used by
anything AFAIK, certainly not by the fedora.us kernel-module packages anyway.

That's not to say this topic doesn't deserve a separate discussion of course :)

[Axel Thimm]

==================== Disttag schemes: pick one!
Here are the discussed schemes (some others exist with small
variations, e.g. fc instead of fdr, or no fdr tag at all, the
discussion is the same). Default versioning is (no cvs/beta, kernel
<name>-<upstream version>-<releasenumber><disttag><non sort relevant suffixes, e.g. repoid>
e.g. simply
foo-1.2.3-4.<disttag>.johnsmith
A B C
Red Hat Linux 7.3 fdr0.7.3 rh7.3 rh7.3
Red Hat Linux 8.0 fdr0.8.0 rh8.0 rh8.0
Red Hat Linux 9 fdr0.9 rh9 rh9
Fedora Core 1 fdr1 rh9.1 1fdr
Fedora Core 2 test1 fdr1.95 rh9.1.95 1.95fdr
Just to be 100% clear I am soon posting my revised package naming
counter-proposal for fedora.redhat.com.
%{X}.%{disttag}
Where %{X} is the vepoch and %{disttag} is a distribution tag from this
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

So this is scheme A, with the variation of dropping the distid.

[Mike A. Harris]

Post by Warren Togami
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...

Post by Warren Togami
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.

Post by Warren Togami
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!

Post by Warren Togami
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.
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.
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>)

Post by Warren Togami
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.
foobar-1.2.3-1.src.rpm compiles to
foobar-1.2.3-1.i386.rpm
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)

Post by Warren Togami
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.
0.%{X}.%{alphatag}
%{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that
came from the version.
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
alsa-lib-0.9.2beta1.tar.gz becomes
alsa-lib-0.9.2-0.1.beta1
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?

Post by Warren Togami
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.
%{X}.%{disttag}
Where %{X} is the vepoch and %{disttag} is a distribution tag from this
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
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
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)

Post by Warren Togami
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)

Post by Warren Togami
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}
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.

Post by Warren Togami
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

[Axel Thimm]

Post by Mike A. Harris
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?

Post by Mike A. Harris
Are there cases where rpm would consider imap-2000a as older than
imap-2000?

No, not since rpm >= 4.0.3 (#21392).

[Warren Togami]

Post by Mike A. Harris

Post by Warren Togami
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.

Post by Mike A. Harris

Post by Warren Togami
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.
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.
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.

Post by Mike A. Harris

Post by Warren Togami
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.
0.%{X}.%{alphatag}
%{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that
came from the version.
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
alsa-lib-0.9.2beta1.tar.gz becomes
alsa-lib-0.9.2-0.1.beta1
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.

Post by Mike A. Harris

Post by Warren Togami
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.
%{X}.%{disttag}
Where %{X} is the vepoch and %{disttag} is a distribution tag from this
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
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
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

[Nicolas Mailhot]

Post by Warren Togami

Post by Mike A. Harris
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,

[Panu Matilainen]

Post by Nicolas Mailhot

Post by Warren Togami

Post by Mike A. Harris
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-***@0.9.i386.rpm. Looks lovely doesn't it :)

<ducks and runs>

- Panu -

[Chuck Wolber]

Post by Warren Togami
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:)

I hate me too posts... But... aw heck... me too...

-Chuck

[Michael Schwendt]

Post by Warren Togami

Post by Mike A. Harris

Post by Warren Togami
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.
0.%{X}.%{alphatag}
%{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that
came from the version.
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
alsa-lib-0.9.2beta1.tar.gz becomes
alsa-lib-0.9.2-0.1.beta1
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.

--

[Ville Skyttä]

Post by Michael Schwendt

Post by Warren Togami
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?

[Warren Togami]

Post by Ville Skyttä

Post by Michael Schwendt

Post by Warren Togami
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

[Axel Thimm]

Post by Warren Togami
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. ;)

[Jesse Keating]

Post by Axel Thimm
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.

[Nicolas Mailhot]

Post by Jesse Keating

Post by Axel Thimm
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,

[Ville Skyttä]

Post by Nicolas Mailhot

Post by Jesse Keating

Post by Axel Thimm
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?

[Jesse Keating]

Post by Ville Skyttä
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?

Please see Warren Togami's naming scheme proposal. Unless otherwise
opposed, Fedora Legacy will adopt this naming scheme and move forward
with it.

[Mike A. Harris]

Post by Axel Thimm

Post by Warren Togami
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!

[Lamar Owen]

Post by Mike A. Harris
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.

[Jesse Keating]

Post by Mike A. Harris
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.

[Axel Thimm]

Post by Axel Thimm

Post by Warren Togami
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?

[Jesse Keating]

Post by Axel Thimm
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?

Alex, calm down. It has been proposed, then modified slightly (which I
forgot) by Warren, to just upgrade to the latest that rpm.org has to offer
for each respective os. There were reasons posted as well. At the time,
nobody seemed to oppose it. Now there seems to be some opposition. No
need to get your feathers ruffled, we can discuss it once more. We have
until mid December to make some decisions.

- --
Jesse Keating RHCE MCSE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating

[Nils Philippsen]

[...]

Post by Michael Schwendt

Post by Warren Togami

Post by Mike A. Harris
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.

Post by Michael Schwendt
* 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 ;-).

Post by Michael Schwendt
* The road of least surprise (with regard to upstream versioning).

That's what I want.

Post by Michael Schwendt
* 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

[Michael Schwendt]

Post by Nils Philippsen
[...]

Post by Michael Schwendt

Post by Warren Togami

Post by Mike A. Harris
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

Post by Nils Philippsen
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.

Not "might be necessary", it is a strict requirement by RPM.

Post by Nils Philippsen

Post by Michael Schwendt
* 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.

Post by Nils Philippsen

Post by Michael Schwendt
* The road of least surprise (with regard to upstream versioning).

That's what I want.

Post by Michael Schwendt
* 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?

Post by Nils Philippsen
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.

--

[Mike A. Harris]

Post by Warren Togami

Post by Mike A. Harris
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.

Post by Warren Togami

Post by Mike A. Harris
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!"

Yeah, this is a very good way to work around a not uncommon
problem.

Post by Warren Togami
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)

Post by Warren Togami

Post by Mike A. Harris
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 "."

Hmm. Good point. Perhaps it just needs some getting used to.

Post by Warren Togami
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)

[Rex Dieter]

Post by Warren Togami
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.
%{X}.%{disttag}

...

Post by Warren Togami
foobar-1.2.3-1_0.7.3.i386.rpm

Did you mean %{X}_%{disttag} or %{X}.%{disttag}?? I guess either one
works, as long as you're consistent.

-- Rex

[Peter Bowen]

Post by Warren Togami
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