Avoiding package meltdown with APT source pinning

Debian’s release cycle is pretty sedate, which means the distribution you have installed will be solid and stable, but there will undoubtedly be more recent versions of programs available than you have installed. The safest and most easily reversed way of locating and installing the latest or at least more recent versions of software is to point the apt-get package manager to the Debian repositories that contain the upcoming Debian distribution releases, using apt’s sources.list file. This is how to do that.

This is done by editing the /etc/apt/sources.list file, from which apt-get reads the locations of .deb package repositories to check for updates. Typically the primary repository would be the version installed. For example:

## DEBIAN
deb http://ftp.de.debian.org/debian/ squeeze main contrib non-free

## DEBIAN SECURITY
deb http://security.debian.org/ squeeze/updates main

The Debian release cycle is made up of three distributions:

  • the current, stable release (currently squeeze, but referred to as stable)
  • the next release undergoing testing (currently wheezy, but referred to as testing)
  • the experimental release being actively developed (known as sid, but referred to as unstable).

Additionally, some more recent versions of applications from testing and unstable are repackaged for the current release, known as backports and made available from the backports repository. We can add these to sources.list, for example:


## DEBIAN TESTING (wheezy)
deb http://ftp.de.debian.org/debian/ testing main contrib non-free

## DEBIAN BACKPORTS
deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free

Running apt-get update will send apt-get off to prepare a new list of packages that can be upgraded or installed. But running apt-get upgrade with the sources.list looking like this would result in installing an unholy mix of possibly conflicting packages from different repositories. To safely use this technique, we need to also edit the /etc/apt/preferences file. It looks like this:


Package: *
Pin: release n=squeeze
Pin-Priority: 100

Package: *
Pin: release a=testing
Pin-Priority: -10

Package: *
Pin: release a=squeeze-backports
Pin-Priority: 10

See the manpage for apt_preferences for chapter and verse on how this works, but the key part is the pin-priority. Sources pinned with a higher priority will be selected over lower priorities. Sources pinned with a number below zero – such as the testing repository above – will never be used except when specifically called with apt-get -t . So to install the latest version of a popular music player from the testing repository to replace the version in the current, stable branch, you’d use:

sudo apt-get -t testing install audacious audacious-plugins

This method means you can have multiple repository sources lined up on the system, to be called upon when required. Running apt-get dist-upgrade will still only use the default repos (squeeze, in this case), whereas apt-get -t squeeze-backports dist-upgrade will upgrade every package available from the backports repo, and apt-get -t testing dist-upgrade will attempt to effectively replace the current stable distribution with that of the testing release.

A good addition to note is the --no-act switch – Not only does it prevent apt-get from actually making any changes, but it also verbosely states for each package it suggests changing which repository the upgrade will come from, allowing you to track which version is coming from where. The end result is a system whose package structure is much more easy to upgrade or manipulate than if we had downloaded the most recent version and compiled from source.