Probably why Fedora puts their release version in package release numbers

April 9, 2015

Packaging schemes like RPM and Debian debs split full package names up into three components: the name, the (upstream) version, and the (distribution) release of the package. Back when people started making RPM packages, the release component tended to be just a number, giving you full names like liferea-1.0.9-1 (this is release 1 of Liferea 1.0.9). As I mentioned recently, the modern practice of Fedora release numbers has changed to include the distribution version. Today we have liferea-1.10.13-1.fc21 instead (on Fedora 21, as you can see). Looking at my Fedora systems, this appears to be basically universal.

Before I started writing this entry and really thinking about the problem, I thought there was a really good deep reason for this. However, now I think it's so that if you're maintaining the same version of a package on both Fedora 20 and Fedora 21, you can use the exact same .spec file. As an additional reason, it makes automated rebuilds of packages for (and in) new Fedora versions easier and work better for upgrades (in that someone upgrading Fedora versions will wind up with the new version's packages).

The simple magic is in the .spec file:

Release: 1%{?dist}

The RPM build process will substitute this in at build time with the Fedora version you're building on (or for), giving you release numbers like 1.fc20 and 1.fc21. Due to this substitution, any RPM .spec file that does releases this way can be automatically rebuilt on a new Fedora version without needing any .spec file changes (and you'll still get a new RPM version that will upgrade right, since RPM sees 1.fc21 as being more recent than 1.fc20).

The problem that this doesn't really deal with (and I initially thought it did) is wanting to build an update to the Fedora 20 version of a RPM without updating the Fedora 21 version. If you just increment the release number of the Fedora 20 version, you get 2.fc20 and the old 1.fc21 and then upgrades won't work right (you'll keep the 2.fc20 version of the RPM). You'd have to change the F20 version to a release number of, say, '1.fc20.1'; RPM will consider this bigger than 1.fc20 but smaller than 1.fc21, so everything works out.

(I suspect that the current Fedora answer here is 'don't try to do just a F20 rebuild; do a pointless F21 rebuild too, just don't push it as an update'. Really there aren't many situations where you'd need to do a rebuild without any changes in the source package, and if you change the source package, eg to add a new patch, you probably want to do a F21 update too. I wave my hands.)

PS: I also originally thought that Ubuntu does this too, but no; while Ubuntu embeds 'ubuntu' in a lot of their package release numbers, it's not specific to the Ubuntu version involved and any number of packages don't have it. I assume it marks packages where Ubuntu deviates from the upstream Debian package in some way, eg included patches and so on.


Comments on this page:

By Dominic at 2015-04-09 03:25:44:

I'm not very familiar with Debian development, so I wonder how if there's no distinguishing feature in the version number, how they deal with mass-rebuilds triggered by a base package?

Fedora tend to mass rebuild packages on most releases to pick up new compiler features or changed compiler defaults (e.g. to enable security flags). Here's an example: https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild. Perhaps Debian doesn't see the same need, or just handle it on the next regular update to that package.

Interesting timing of your entry, as I'm considering a similar feature to %dist in a set of application packages that I co-maintain. We have a base application package which adds some RPM macros and changes between major versions, then plugins which are built against the main app package. The plugins may need rebuilding on new major versions to pick up build-time changes in the RPM macros, which are used in %post. If we build plugin 1.2.0-1 against two base application versions then they may result in different binary RPMs due to macro differences.

I'm considering adding a -release package to our build environments like Fedora's, which deploys /usr/lib/rpm/macros.d/macros.dist and sets %dist, in order to use %{app_dist} in our own release fields.

By dozzie at 2015-04-09 08:31:37:

@Dominic:

[...] how they deal with mass-rebuilds triggered by a base package?

They don't. There's no such thing as mass rebuild because of new upstream version. Once something lands in Debian stable (or rather, is frozen as Debian stable), it doesn't change anymore, except for (backported) security updates.

By Ben Hutchings at 2015-04-09 08:59:19:

Dominic: "I'm not very familiar with Debian development, so I wonder how if there's no distinguishing feature in the version number, how they deal with mass-rebuilds triggered by a base package?"

We don't do mass-rebuilds, but if we need to rebuild a source package without a source change (called a 'binNMU') the new binary version gets a '+b<n>' suffix to the version number.

For package versions that go into both stable and unstable (this doesn't happen very often, but iceweasel would be an example), generally the version in unstable doesn't get any distribution marker but the version in stable gets a suffix of '~deb<x>u<y>' ('~' sorts lower than the empty string). This allows for multiple updates to stable without breaking the ordering.

By Dominic at 2015-04-10 03:08:08:

dozzie, I was thinking more about development of unstable than updates to stable. e.g. taking the Fedora example, a new version of GCC lands and a rebuild of packages using it is done so they pick up optimisations.

Ben, thanks for the explanations. The tilde operator is a very handy feature, that example neatly solves the ability to upgrade.

Written on 09 April 2015.
« Your entire download infrastructure needs to use HTTPS
My Firefox 37 extensions and addons (sort of) »

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

Last modified: Thu Apr 9 00:50:23 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.