The Grumpy Troll

Ramblings of a grumpy troll.

RPM version labelling

For those experienced with RPMs, this post will doubtless be hilarious in its naïveté.

This troll has recently had to start dealing with RPM-based Linux systems. The .spec file system is "interesting", with documentation scattered and incomplete. Debian's and FreeBSD's systems are much cleaner and better documented, but RPM is what I have to deal with.

One thing I've noticed when building site-local RPMs for software is that people tend not to worry about a future OS upgrade bumping version numbers of the upstream package to where a locally-built package is replaced, or how packages will be disambiguated if upstream has the same version number.

Not clearly documented where I could find it, there is a way to deal with this, through convention. What I see in many .spec files is that the packager defined the OS release (the suffix to the upstream version) as something like:

Release: 1%{?dist}

By editing “~/.rpmmacros” to specify:

%dist mysite

You can end up with Version: 2.34 of Name: foo being built as “foo-2.34-1mysite”.

The %{?macro} expansion expands to the empty string if that macro has not been defined.

This works where everyone edits ~/.rpmmacros or your local build tools take control of it. You might adjust the site-wide macros to do this for all builds on this machine. But what about just bundling a default with the RPM spec file?

More searching led to a way around the unclear documentation about whether there's an conditional-block system not tied to OS attributes. There are "if-not-defined" macro expansions, so I ended up with this:

%define sitedist %{?dist}%{!?dist:mysite}
Release: 1%{?sitedist}

Result: if someone specifies %dist in ~/.rpmmacros then it will work as expected. If they do not, then a default of “mysite” will be used instead.

-The Grumpy Troll, stumbling around at neophyte level
Categories: Linux RPM versioning