Insserv: The Final Word

I updated my two Debian sid systems to insserv and dependency based booting today. The update was on hold for so long (over a year!) that it was growing a fungus. ^_^

After the positive experience with the Debian squeeze upgrade, and the fact that some packages are now depending on insserv (shudder), I decided that not updating was likely to become troublesome in the near future. The one thing that you should never do on Linux, is fight against the package dependencies, even if you don't agree with them. Thither lies dependency hell. Trust me, you have better things to do.

Hopefully, this will be the final word on insserv. Unless it breaks, of course. ^_^

Dependency Based Booting

I have had the sysv-rc package on hold on my Debian sid desktop system for several weeks now. If I upgrade sysv-rc, it will install the insserv package which will setup a dependency based boot sequence. So far I haven't had the nerve to take that step yet. At the moment, there are no critical bugs reported against either package so the upgrade should just work.

And yet I am still hesitant. Just call it intuition.

Using Debian Sid Safely

Running Debian Sid on your desktop system is somewhat intimidating. After all, it is named after the unstable Toy Story character for good reason. I have three defensive strategies which has save me endless grief. As a result, I haven't been locked out of my desktop since the time the bash package scripts blew up and left the system with any functional shell. (Can't find any bug report about that one, it only gets mentioned in the changelog for package version 2.02.1-1.7 when the preinstall became a C program in August 1999.)

Here's what I do to keep Sid calm.

First, I get my packages from a secondary Debian mirror. This buys a couple of days grace before I see the buggy package. By that time the news has hit the debian-user mailing list, so I get advanced warning of the impending problem. When I eventually see the dangerous package, it a simple matter of putting it on hold and waiting for the fixed version.

Second, I use apt-listbugs. Nobody should be using Sid without this utility installed. From the package description:

apt-listbugs is a tool which retrieves bug reports from the Debian Bug
Tracking System and lists them. Especially, it is intended to be invoked
before each upgrade/installation by apt in order to check whether the
upgrade/installation is safe.

Specifically, apt-listbugs displays any critical bugs for the packages to be upgraded and allows you to abort the upgrade if you see something that makes you nervous. I've lost track of how many times apt-listbugs has saved me.

Third, I keep a few older versions of packages. I do this with apt-cacher which actually maintains a local mirror of all packages I've installed, but it doesn't really matter how how you keep the packages. The important point is to have some way to downgrade the package if the previous lines of defence fail, and I end up installing a broken package.

The above procedures seem to cover most cases. A recent problem with cups (Common Unix Print System) and USB printers was never mentioned on the mailing list, and was not reported as a critical bug, so I installed the broken package. Of course, I only discovered the problem when I had to print something... But downgrading the cups packages temporarily was still an option, so I was able to continue until I found a permanent fix. Another example is an recent X server upgrade started crashing, but I avoided the mess because apt-listbugs showed me the bug report before it was mentioned on the mailing list.

Sid will break; that is guaranteed. But if you plan for it, Sid is safe for everyday use, and you get to play with the very latest software. Not a bad bargain.