Pinning down Etch backports September 30th, 2007
For a while, I've wanted kde-3.5.7 on my Debian 4.0 (Etch) laptop. It's available in the etch-backports archive from backports.org. But the etch-backports archive contains a lot of other backported packages, and I want to stick to Etch with the exception of KDE.
You may ask why I don't just accept all packages from the etch-backports archive. There are two reasons: stability and security.
With respect to stability, I reckon that the packages in the etch archive have probably been exposed to the largest number of users. Assuming that a wider user base leads to more bug reports and fixes, these packages would be the most stable. That assumption doesn't always hold, but it's a good generalisation, as generalisation's go.
An enormous amount of effort goes into producing a stable Debian release, and I want to maximise my leverage of that effort. As I become more of a manager, my interest in a bleeding edge laptop wanes.
As for security, the Debian Security Team FAQ suggests that the testing archive can receive security updates less frequently than the etch archive. Since the general backports.org policy is to backport only from the testing archive, I figure I'd wait longer for security updates from the etch-backports archive.
So for the most part, I want packages from the etch archive. For KDE, a suite of hundreds of packages, I want what's in the etch-backports archive.
The solution, as presented by the instructions at backports.org, is to use APT preferences to pin specific packages to the etch-backports archive. Unfortunately, the format of the APT preferences file requires that you pin every single package of the KDE suite. With a full KDE installation comprising over 200 packages.
This seemed like it would be a lot of work, especially since I couldn't find the list of packages for the KDE suite in a single list. Rather, I'd have to navigate an extensive dependency tree, ignoring dependencies that aren't part of the KDE suite.
However, I noticed that all the packages from the KDE suite contain the same text in their long descriptions:
This package is part of KDE
How fortunate. Especially since the dctrl-tools package provides a way to search for packages matching against any header in the package control file.
So after following the instructions at backports.org to add the etch-backports archive to my APT sources and update my package index files from their sources, here's what I did to tell APT to accept KDE packages, but nothing else, from etch-backports:
aptitude install dctrl-tools
grep-aptavail -ns Package -F Description \
"This package is part of KDE" | sort | \
for pkg in `cat`; do
echo
echo Package: $pkg
echo Pin: release a=etch-backports
echo Pin-Priority: 999
done >> /etc/apt/preferences
aptitude dist-upgrade
The grep-aptavail options instruct it to print out the value of the Package header (but not the name of the header) for all packages available to APT with a Description header that contains "This package is part of KDE". In short, it prints a list of all packages in the KDE suite. The output is then sorted, transformed into a set of APT preference records, and appended to the APT preferences.
Now I can rest assured that any packages I install from the KDE suite will be installed from the etch-backports archive, but other packages available in etch-backports will not be installed unless I deliberately pin them too.
The same approach works for OpenOffice.org. In fact, it's likely to work for any suite of software where the package maintainers have done something sensible with the package descriptions. All packages in the OpenOffice.org suite contain this text in their descriptions:
OpenOffice.org is a full-featured office productivity suite
Now you can have the toys that the cool kids have, without being cool.