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 over 9 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

Also available in: Atom PDF