ambiguity: RPM versions with an epoch

[bradcupit]

The README says:

the version is the combined epoch (if not 0), version and release of an RPM.
but the list of RPM examples doesn't include any with an epoch:

pkg:rpm/fedora/[email protected]?arch=i386&distro=fedora-25
pkg:rpm/opensuse/[email protected].?arch=i386&distro=opensuse-tumbleweed

Question: how should we combine the epoch with the version?

[bradcupit]

I can think of 3 different ways.
Assuming epoch=4:

1. pkg:rpm/fedora/curl@4:7.50.3-1.fc25?arch=i386
   Though having a colon in the URL might make this an illegal URL

2. pkg:rpm/fedora/curl@4%3A7.50.3-1.fc25?arch=i386
   This example's URL encodes the colon.

3. pkg:rpm/fedora/[email protected]?arch=i386
   Just use a dash (so the format is {epoch}-{version}-{release}

Epoch

For those unfamiliar with epoch here's a quick description:

If the version number is not enough to allow for comparisons, for example, if the version numbering scheme has changed radically between releases, you can define an Epoch: directive. For example:
Epoch: 3
If you renumber your versions, use an Epoch setting to clarify the version history. For example, Sun Microsystems went from SunOS 4.1 to Solaris 2. The Epoch: helps RPM properly handle strange version number changes. Define the Epoch: as a whole number such as 1, 2, or 3.
Warning
Avoid using the Epoch: directive if at all possible. It is far better to use a sane version-numbering scheme than to try to resolve the mess with epoch values. The main problems with using an epoch value are that epochs are hidden from users in most cases

-- from https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s03.html

[jdillon]

Personally I think epoch should be encoded as a qualifier, as its not really part of the version, just a hint about how to order versions? Having to cope with version with epoch and version w/o epoch puts extra burden on consumer as well.

[bradcupit]

I did some more research and found this which says:

The Epoch: tag provides the most significant input to RPM’s version comparison function. If present, it MUST consist of a positive integer.

Since it's the most significant maybe it should be furthest left, and part of the version?

And when combined with this from the same link:

It’s possible that upstream uses characters besides ASCII letters (upper and lower case), digits and periods in its version. They must be removed

and this link:

epoch

• Deprecated
• A single (generally small) unsigned integer
• Zero if omitted
• Used for packager versioning mistakes, should not be used regularly

version

• Mandatory
• Characters NOT allowed: - / ~ .. (hyphen, slash, tilde, double dot)
• Spaces not allowed

release

• Optional
• Characters NOT allowed: - / ~ .. (hyphen, slash, tilde, double dot)
• Spaces not allowed

It seems like hyphens aren't allowed, so I think we'll go with a solution @jdillon suggested to me privately and use hyphens as a separator, which doesn't require URL encoding. Basically: {epoch}-{version}-{release} and omit epoch when it's 0 or absent. Example:

pkg:rpm/fedora/[email protected]?arch=i386

[jdillon]

BTW the 0 or absent seems like a pretty nasty wrinkle to prefixing the version with this value. This means that for rpm:/ type you now have to additionally do additional checking version to actually get the version w/o epoch if that is what you are really after.

I still strongly recommend that epoch should be encoded as qualifier and leave version alone.

pkg:rpm/fedora/[email protected]?arch=i386&epoch=4

[stevespringett]

If present, it MUST consist of a positive integer.

To me, this indicates it's optional but useful in fine tuning version comparisons. Agree with @jdillon. I think epoch should be a qualifier with a recommendation that it be used.

[pombredanne]

I like using a qualifier for epoch. 👍

It makes sense too for Debian packages that have a similar concept.

In both cases, the epoch purpose is:

• ESSENTIAL for version comparison and dependencies resolution,
• NOT part of the things used to uniquely identify a package.

They are part of the metadata and not of the package archive filename for instance.

See for instance these two that both use an epoch (both epoch 1)

• http://mirror.centos.org/centos/7/os/x86_64/Packages/mod_ssl-2.4.6-90.el7.centos.x86_64.rpm
• http://mirrors.kernel.org/ubuntu/pool/main/e/erlang/erlang-base_21.2.6+dfsg-1_amd64.deb

[iamwillbar]

I agree that the epoch should be a qualifier and not part of the version number, the version number is intended for opaque equality comparison whereas the epoch is intended for ordering. Ordering could be useful for other package managers that don't have sortable version numbers so making the epoch a qualifier could be generally useful.

[wgwoods]

Hrm. Epoch feels like a qualifier - it's optional, uncommon, and its main purpose is version ordering. But I'm not sure you can ignore it for "equality comparison", because epoch is definitely part of RPM's equality comparisons in a way that qualifiers like "arch" are not.

For Fedora & derivatives (CentOS, RHEL, &c) you can safely assume that two packages with the same NVR but different arches came from the same source RPM. So these:

• pkg:rpm/fedora/[email protected]?arch=i686
• pkg:rpm/fedora/[email protected]?arch=x86_64

are two builds of the same sources and should be functionally equivalent. On a multi-arch system, RPM will consider a requirement for "curl = 7.66.0-1.fc31" satisfied if either package is installed. So those can probably be considered "equal" in most contexts where you don't care about arch.

On the other hand, if these two packages exist:

• pkg:rpm/fedora/[email protected]?arch=x86_64
• pkg:rpm/fedora/[email protected]?arch=x86_64&epoch=1

they're definitely from two different source RPMs. It would not be safe to assume they were built from the same sources, or that a bug fixed in the latter build is fixed in the former. RPM would consider a requirement for "curl = 7.66.0-1.fc31" unsatisfied if the latter package was installed.

I don't know what guarantees/expectations there are for uniqueness of unqualified purls, so I don't know if this would cause problems or not, but that worries me a little.

[iamwillbar]

Thanks, @wgwoods. I think this supports epoch being a qualifier since PURL doesn't make any explicit claims about how to compare PURLs and is consistent with the definition usage should be limited to the bare minimum for proper package identification.