Project

General

Profile

Actions

Bug #3535

closed

RPM packages: upgrades from one major branch to another don't always work because of the Epoch field

Added by Jonathan CLARKE over 11 years ago. Updated almost 10 years ago.

Status:
Released
Priority:
1 (highest)
Assignee:
Jonathan CLARKE
Category:
Packaging
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

We insert the build-time timestamp into the RPM's Epoch field when building packages, in order to ensure that subsequent versions are "greater" in version number than older ones. This is particularly necessary because we do releases like 2.5.0.alpha1, 2.5.0.beta1, 2.5.0, which should be in that order but are not otherwise considered in that order with RPM's version comparaison algorithm. See http://serverfault.com/questions/454462/incremental-rpm-package-version-numbers-for-x-y-z-x-y-z-beta-or-alpha-rc.

The way RPM uses the Epoch field is to prefix it to the Version field, and then compare those as a full version number. This causes problems when upgrading from one major version of Rudder to another, because a 2.5 package may have been built more recently (therefore with a bigger timestamp in the Epoch field) than a 2.6 package.


Related issues 2 (0 open2 closed)

Related to Rudder - Bug #3558: RPM packages: upgrades from one major branch to another don't always work because of the Epoch field (backport in 2.5)ReleasedMatthieu CERDA2013-04-29Actions
Related to Rudder - Bug #7777: Rudder-agent provides rudder-agent without a versionReleasedJonathan CLARKEActions
Actions #1

Updated by Jonathan CLARKE over 11 years ago

  • Project changed from Rudder to 34

A workaround would be to prefix the timestamp we put into the Epoch field with the Rudder major version, ie 2.5. This way, within releases from one major version, the latest is always viewed at the highest version, but a higher major version of Rudder always wins.

I'm looking into how to implement this.

Actions #2

Updated by Jonathan CLARKE over 11 years ago

So it turns out (see http://stackoverflow.com/questions/1615291/does-the-rpm-epoch-header-have-any-limitations) that the Epoch field in RPM has a maximum size of a 32 bit unsigned int (ie 2,147,483,647). And with the current timestamp being 1,366,896,844, we can't prefix anything to this without an overflow.

So another approach would be to use version suffixes that are in alphabetical order, like these:

  • 2.4.0.alpha1
  • 2.4.0.alpha2
  • 2.4.0.beta1
  • 2.4.0.beta2
  • 2.4.0.rc1
  • 2.4.0.rc2
  • 2.4.0.release
Actions #3

Updated by Jonathan CLARKE over 11 years ago

  • Status changed from In progress to Pending technical review

This has been fixed on our internal build script by suffixing all RPM versions that are final releases with ".release". The Epoch has been fixed at 1366900520 and will no longer be incremented.

Actions #4

Updated by Jonathan CLARKE over 11 years ago

  • Status changed from Pending technical review to Pending release
Actions #5

Updated by Jonathan CLARKE over 11 years ago

  • Status changed from Pending release to Released
Actions #6

Updated by Benoît PECCATTE almost 10 years ago

  • Project changed from 34 to Rudder
  • Category set to Packaging
Actions #7

Updated by François ARMAND over 7 years ago

  • Related to Bug #7777: Rudder-agent provides rudder-agent without a version added
Actions

Also available in: Atom PDF