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

Re: Warren's Package Naming Proposal - Revision 1

Mike A. Harris wrote:

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.


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


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:
Release Tag for Non-Numeric Post-Release Packages:

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

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

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

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?


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


Upgrade Path Example (FC1 only shown):

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.


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