Do your homework before dist-upgrading…

The other week I thought I’d upgrade the desktop machine from Debian Etch to Lenny (the testing branch, to be marked stable, well, sometime soon anyway). I was in for some surprises, which I’ll tell you about, but luckily there was a backup at hand, and on the second attempt I had a fairly smooth upgrade. I believe that was still somewhat by chance rather than by any wisdom though, so please don’t do what I describe here!

In imprecise terms, I ran into a problem with (pseudo-)circular dependencies – if packages are upgraded in the wrong order (which should only happen if some of them don’t strictly adhere to best-practices of package management) you may end up with a package in an unconfigured state, while it is needed to upgrade other packages, including the packages on which it itself depends for further configuration.

Or something like that.

Ignorant as I am, I didn’t look into any of the release-critical bugs that still keep Lenny from release, and ran into such a problem with perl. I had no clue why my package manager ground to a halt, and then made things worse by accepting its obviously bad attempts at restoring order – it suggested the removal of a few hundred packages…  and I accepted the suggestion.

Short break for you to stop laughing.

So only then did I go and look for information, and came across this bug report, which probably summarises the problem I had run into. I also found these notes, which could have saved me had I not further borked the upgrade after it got stuck.

What these issues highlight, I think, is what an amazing system we have for package management; despite the tens of thousands of packages in the repositories, which presumably will have highly non-trivial interactions amongst them, problems like this hardly ever occur and in fact it seems they only do occur when mistakes are made in packaging. I cannot imagine how someone has ever managed architecting this system.

In the end I gave up and restored the backup I made just before dist-upgrading. Better prepared this time, I helped the package manager a bit with planning the upgrade: I started by issuing a “dpkg -i perl_5.10.0-13_i386.deb perl-base_5.10.0-13_i386.deb perl-modules_5.10.0-13_all.deb” (from the archives dir, see below) – which didn’t succeed of course, but it did change the order of upgrades sufficiently that this time everything went smoothly. The next two steps were a normal upgrade, then a dist-upgrade (in the new aptitude version these are called safe-upgrade and full-upgrade).

So, my advice then: don’t do as I did, and read up a bit on the task before diving in, and of course run a backup first. In addition, I was happy I had fetched the upgrade-packages in a separate step (if you use aptitude, you can use the “-d” switch for this) – this way at least I didn’t have to load the network again to re-fetch a couple of hundred MBs after restoring the backup. In my case, I had made the packages part of the backup, but there are more efficient ways I suppose. The packages are cached in /var/cache/apt/archives. Have fun!


    %d bloggers like this: