Some opinions on how package systems should allow you to pin versions

December 21, 2015

Good package management systems allow you to selectively pin or freeze the versions of some packages. Over time I have evolved some opinions on how this should work, usually by getting irritated by the limitations of some tool in doing this (which is what happened today). So here is the minimum things that your package management tool should support around this.

First, you should be able to pin a package at a version that is not the currently installed version. Such a pin means that the package system is allowed to upgrade the package to that version and no other. Ideally such a pinned version would anchor the update of other packages which require synchronized versions.

(Bonus points are awarded if the package system can be made to downgrade a package to that version as well.)

Second, you should be able to pin the version of a package that is not even installed. Such a pin means that only that version of the package is allowed to be installed later. As with the previous case, a 'can only install version X' pin should influence other packages through dependencies and so on.

When both situations primarily matter is during system installation where you will be applying package updates (which is often the case). If you can pin non-current versions and even future package installs, your install system has a simple workflow; it first installs all of your pins, then does its usual package updates and installations of extra packages without worrying about specific versions. If you cannot pin non-current or non-installed packages, knowledge of pinned packages (and their versions) leaks into the whole update and install process. When you apply updates, you have to limit some packages to be updated only so far; when you install new packages, you have to install specific versions of some packages. And on top of this you have to pin (or hold, or freeze) the packages as well, so that future updates won't undo your work of picking specific package versions.

(This can also matter later on if you decide that you now want to pin some additional packages before applying more updates or installing new packages.)

Sidebar: pinning specific versions versus holding back changes

Sometimes you want a specific version of a package because it's what you've determined will work, or because you want all systems to be the same for some important package, or the like. Other times you don't particularly care about the specific version, but you just don't want a package to change for various reasons (for example, kernel updates might require reboots which have to be scheduled well in advance, or grub updates often wind up causing problems for your update process).

In theory, holding package changes is a subset of pinning a specific version (it is 'pin the current version of the package'). In practice package managers that support both often implement the two in different ways. I believe that Debian apt is an example of this.


Comments on this page:

By dozzie at 2015-12-24 05:10:10:

Well, APT does have pinning ( man apt_preferences ), and it works for stuff already installed and for future installations. If you choose priorities appropriately, it should even be able to downgrade current versions to what you have specified. It's underdocumented in my opinion, though, and difficult to assess whether your configuration works or not (apt-cache policy $pkgname helps, but its output is not totally clear).

Written on 21 December 2015.
« The Apache mod_qos module worked for us
Where cryptographic hashes come into TLS certificates »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon Dec 21 21:39:41 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.