Nailing down RPM epoch numbers

January 5, 2012

As I mentioned here, RPM package version numbers have three components: an 'epoch' number, the package's upstream version, and an RPM package release version. The epoch number is there because upstream developers sometimes change version numbers in ways that break RPM's normal version comparison algorithm, or just plain use odd version formats.

(For example, I believe there's at least one program that increments its version by adding another digit of π to the end of the version number. This makes perfect sense in a way, but is hard for RPM version comparison to cope with.)

In that other entry I wrote that the default epoch number was '1' (and then a commentator corrected me to say that it was '0'). Both of us turn out to be wrong. The default RPM versioning is to have no epoch number at all. A RPM package that does not specify an epoch number does not have an epoch of '0'; it has no epoch at all, which is displayed by RPM as '(none)'. A package with no epoch number is a lower version overall than any epoch number, even 0.

On all of the RPM-based machines that I have sitting around, no epoch is by far the most common epoch. The next most common epoch is actually '1', not '0'; one theory I have about this is that a lot of people who build RPMs also think that the default epoch is 0, so when they specify an explicit epoch to override the upstream version number they start from 1.

Across all of the packages that I have handy on my machines, the highest epoch number is 50 (on aspell-en, on Fedora 14, Fedora 15, and Fedora 16). Other high epochs (on Fedora 16) are 32 (for bind's packages), 14 (tcpdump plus libpcap), and 12 (dhcp and aspell).

If you want to check your own RPM-based systems, appropriate rpm commands are:

rpm -qa --qf '%{E}\n' | sort | uniq -c | sort -nr
rpm -qa --qf '%{E}:%{N}\n'

The first will show you a count of epoch numbers; the second will show you the epochs for all of your packages (so you can find, for example, the package or packages at epoch 50).

Comments on this page:

From at 2012-01-06 13:08:55:

TeX does the pi thing, but it isn't generally packaged on its own. (Metafont, a related tool, uses e as the version number.)

From at 2012-01-06 13:38:25:

3.1 < 3.14 < 3.141 < 3.1415, where is the problem?

From at 2012-01-06 15:11:34:

The default RPM versioning is to have no epoch number at all. A RPM package that does not specify an epoch number does not have an epoch of '0'; it has no epoch at all

Ok, yes, that's kind of true. You can technically tell the difference between epoch=0 and epoch=None ... but in practice they are the same. yum (and AFAIK every other package manager) auto converts epoch=None to epoch=0, pretty much everywhere, and recent rpm now also has %{epochnum} (in a huge worship IMO to full backwards compatibility). I have seen random bugs in other software (like repo. updateinfo produced with epoch="None" ... but they have all been bugs, and were worked around in yum and fixed in the generating software). Also when comparing two versions (Eg. for rpm dep-checking) there is no difference (AFAIK) between None and 0 for the epoch.

Really the fact you could (and still can) tell the difference anywhere is a giant bug, but epochnum is as good a fix as we are going to get.

Written on 05 January 2012.
« Disk encryption, backups, and your threat model
Why you might want multiple keys for disk encryption »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jan 5 23:40:41 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.