Policy: No Apt pinning in Debian

Print Friendly, PDF & Email

In Debian package installations are selected from upstream repositories that are tagged with a “release codename”. Most debian installations are “pinned” to a single release, for example the current stable release is “squeeze”. The code names are named after Toy Story characters, if you were wondering. Apt pinning is where packages from a different release codename are installed (with their dependencies) along side the current default. For example, I may want to pin the tomcat6 package from squeeze to a “lenny” installation. I’d do this by adding the sources for squeeze to /etc/apt/sources.list, configuring /etc/apt/preferences to set a higher priority for lenny packages than squeeze (to stop all packages from being upgraded to squeeze) and running:

sudo aptitude install -t stable tomcat6

Apt would pull in the dependencies for the package. (lenny is currently the “oldstable” release.)

However, a few problems with automated installs going wrong and maintaining installs long term have been attributed to the use of pinning. In some cases we have narrowly avoided rendering installations irrecoverable and effectively DOSing ourselves! There isn’t a safe way to configure this to make it future proof as syntax & capabilities can change between releases. In addition, configuration management doesn’t play well with the mix of packages from different releases when attempting to determine dependency chains. Normal “apt-get upgrade” doesn’t always catch the dependencies. Sometimes it’s necessary to search the system (with apt-show-versions) for the release packages that are in to update them and we often see orphaned packages left over from package removals. The migration between releases is much simpler without pinning and normally needs to be disabled during the upgrade. On the whole the risk posed by using pinning is high.

Therefore, I am disabling apt pinning in squeeze (we current rely on it lenny for tomcat6 and a few others) and would like to make a policy of not using it in the future. This does mean that if a package or version of a package which is requested or required does not exist in the current release, the process in order of priority is, find the package in the Debian back-ports repository, retrieve as a source package from the new release repository and back-ported locally (in our own repo) or as a last resort we upgrade the install wholesale to the new release. The most stable option would be to not upgrade the package at all and just wait for the new release to become stable. In the case where numerous unsatisfied dependencies of the package exist, this would be necessary, finding all the dependencies and rebuilding them would be an unacceptable overhead.