Home / server / Questions / 454462
Accepted
Jonathan Clarke
Asked: 2012-12-03 23:52:00 +0800 CST

Incremental RPM package version "numbers" for x.y.z > x.y.z-beta (or alpha, rc, etc)

  • 772

In order to publish RPM packages of several different versions of some software, I'm looking for a way to specify version "numbers" that are considered "upgrades", and include the differentiation of several pre-release versions, such as (in order): "2.4.0 alpha 1", "2.4.0 alpha 2", "2.4.0 alpha 3", "2.4.0 beta 1", "2.4.0 beta 2", "2.4.0 release candidate", "2.4.0 final", "2.4.1", "2.4.2", etc.

The main issue I have with this is that RPM considers that "2.4.0" comes earlier than "2.4.0.alpha1", so I can't just add the suffix on the end of the final version number.

I could try "2.4.0.alpha1", "2.4.0.beta1", "2.4.0.final", which would work, except for the "release candidate" that would be considered later than "2.4.0.final".

An alternative I considered is using the "epoch:" section of the RPM version number (the epoch: prefix is considered before the main version number so that "1:2.4.0" is actually earlier than "2:1.0.0"). By putting a timestamp in the epoch: field, all the versions get ordered as expected by RPM, because their versions appear to increment in time. However, this fails when new releases are made on several major versions at the same time (for example, 2.3.2 is released after 2.4.0, but their version for RPM are "20121003:2.3.2" and "20120928:2.4.0" and systems on 2.3.2 can't get "upgraded" to 2.4.0, because rpm sees it as an older version). In this case, yum/zypper/etc refuse to upgrade to 2.4.0, thus my problem.

What version numbers can I use to achieve this, and make sure that RPM always considers the version numbers to be in order. Or if not version numbers, other mechanism in RPM packaging?

Note 1: I would like to keep the "Release:" field of the spec file for it's original purpose (several releases of packages, including packaging changes, for the same version of the packaged software).

Note 2: This should work on current production versions of major distributions, such as RHEL/CentOS 6 and SLES 11. But I'm interested in solutions that don't, too, so long as they don't involve recompiling rpm!

Note 3: On Debian-like systems, dpkg uses a special component in the version number which is the "~" (tilde) character. This causes dpkg to count the suffix as "negative" ordering, so that "2.4.0~anything" will come before "2.4.0". Then, normal ordering applies after the "~", so "2.4.0~alpha1" comes before "2.4.0~beta1" because "alpha" comes before "beta" alphabetically. I'm not necessarily looking to use the same scheme for RPM packages (I'm pretty sure no such equivalent exists), so this is just FYI.

package-management

5 Answers

  1. Fedora has a set of guidelines for setting the version/release number of pre-release packages. Basically you use the version number of what will be the final release in Version, and start the Release number with 0., an incrementing number, and then alpha, beta or whatever. You would not use an alphanumeric tag final for the final release at all.

    Note that you cannot count on RPM having support for the Debian-style tilde versioning. Several distributions disable this feature.

    • 6
  2. Best Answer

    The official rpm guidelines tell how to do this, and links to an examples page. Here is an example of how you would work with the very common versioning scheme that uses three levels of pre-release (a,b,rc) (which rpm unfortunately makes it slightly complicated to support):

    • 1.0.0a1 -> 1.0.0-0.1.a1
    • 1.0.0b1 -> 1.0.0-0.1.b1
    • 1.0.0b2 -> 1.0.0-0.1.b2
    • 1.0.0b2, second release (packaging tweak of 1.0.0b2) -> 1.0.0-0.2.b2
    • 1.0.0rc1 -> 1.0.0-0.1.rc1
    • 1.0.0 -> 1.0.0-1
    • 1.0.1a1 -> 1.0.1-0.1.a1
    • 1.0.1 -> 1.0.1-1
    • 4

  3. I am not a fan of alpha/beta distinctions. There is released code and unreleased code.

    How I do it: I like the major.minor.build with a continuous integration system (see JenkinsCI). Build integer is never reset. Minor version number changes are for backwards compatible changes. Major number changes are big deals.

    If marketing does not like the "build" to be large integers, you can increment the minor number once for marketing only on builds that are released, and then again when it goes to engineering.

    • 2

  4. I bumped into a similar problem and I had to compare revisions between RedHat, Debian, Python packages and Ruby gems to unify the suite number, and this helped me to evaluate the "greater than" and "less than" in each case:

    This is comparing 1.3.0.post0.dev20180213210433 to 1.3.0, YMMV

    for Red Hat (thanks to https://utcc.utoronto.ca/~cks/space/blog/linux/RPMShellVersionComparison )

    docker run -ti centos:7
yum install rpmdevtools.noarch
rpmdev-vercmp "1.3.0" "1.3.0.post0.dev20180213210433" 
1.3.0 < 1.3.0.post0.dev20180213210433

    For Debian: 

    $ dpkg --compare-versions 1.3.0 gt 1.3.0.post0.dev20180213210433 ; echo $?
1  # false
$ dpkg --compare-versions 1.3.0 lt 1.3.0.post0.dev20180213210433 ; echo $?
0  # true

    For Python

    >>> from pkg_resources import parse_version
>>> parse_version("1.3.0") > parse_version("1.3.0.post0.dev20180213210433")
False
>>> parse_version("1.3.0") < parse_version("1.3.0.post0.dev20180213210433")
True

    For Ruby

    irb(main):001:0> Gem::Version.new("1.3.0") > Gem::Version.new("1.3.0.post0.dev20180213210433")
=> true
irb(main):002:0> Gem::Version.new("1.3.0") < Gem::Version.new("1.3.0.post0.dev20180213210433")
=> false
    • 1

  5. As of version 4.10.0, RPM officially supports the dpkg-style tilde numbering mentioned in the question.

    https://rpm.org/wiki/Releases/4.10.0

    • 0