Another year, another Debian upgrade

[simont]

Last weekend the Debian project released Etch, and so this morning I sat down and upgraded my main home Linux machine. I now have a mostly working Etch system in front of me, which is nice.

The biggest serious problem was the complete replacement of /usr/X11R6/bin with a symlink; Debian automatically got rid of most of the contents of the old directory but missed a few things, resulting in me receiving unhelpful and confusing messages for a while until I lost my patience and started forcibly uninstalling any package that looked as if it was in the way. As it turned out, though, this was in fact the right strategy, so that was all right.

Apart from that, actual headaches during installation were minimal; there were lots of scary-looking package uninstalls, but almost all of them turned out to be because the package in question had been renamed or made virtual, and very few things actually turned up missing when the upgrade was complete.

That said, the two notable things which did end up AWOL, namely MediaWiki and CUPS, both needed reconfiguring nearly from scratch when I reinstalled them. Not too impressed with that, although both appear to be basically working again now. I think.

The single funniest moment of the upgrade, however, was when I was in the middle of a long series of aptitude commands and they suddenly stopped working, because aptitude had somehow contrived to uninstall itself and terminate without installing an upgraded version in its place. That was just breathtakingly impressive; I'm not sure I could have written a packaging system capable of that if I'd tried. Still, when I installed the upgraded aptitude by other means, everything proceeded mostly smoothly from there.

GNOME seems to have made Nautilus more mandatory than before, which is annoying. I quite like the various GNOME bits and pieces such as gnome-panel but dislike my root window being covered in pointless file manager icons, because I prefer using the command line for file management. So I used to get rid of Nautilus by removing it in the session control panel, but that no longer works because it just comes back the next time I log in. I'm currently working around that by means of a nasty script which executes gnome-session-remove nautilus shortly after every login, but that's race-condition-ridden and so I hope to think up a better way at some point.

This post would under other circumstances be a rant, but in fact when I compare this experience to my last Debian upgrade, it looks downright painless by comparison. So, one and a half cheers for Debian this time round; let's see if it can be even less painful next time.

Comments

[shortcipher]

but dislike my root window being covered in pointless file manager icons

I think you want the gconf setting /apps/nautilus/preferences/show_desktop: If set to true, then Nautilus will draw the icons on the desktop.

[filecoreinuse.livejournal.com]

I was just about to post

gconftool-2 --type bool --set /apps/nautilus/preferences/show_desktop false

too

[simont]

Aha, yes, that seems to have done what I wanted. Thanks!

(Bah. I actually looked in /apps/nautilus/desktop, but didn't think to look for a desktop-related option outside that subfolder.)

[ewx.livejournal.com]

I don't know what drugs they were taking when they decided to replace /usr/X11R6/bin with a link. I had the same trouble with that and with aptitude sawing off the branch it was sitting on...

[pm215]

I think the X11R6/bin thing is hard to forgive, because it's obviously just going to cause huge hassles for a lot of people upgrading, and it should have been better handled.

[emperor]

Have you reported a bug about the aptitude thing?

[simont]

Not yet. I'm not entirely sure what information would be required to help them debug it. I have a dirty great session log from the upgrade, but no real confidence that it's usable in its current form and doesn't contain anything private.

If aptitude were to produce a nice goal-seeking log ("I uninstalled this package because it conflicted with that one, which in turn I was installing in response to this, which occurred in furtherance of the following goal which was a direct dependency of the thing you specified on the command line") then I could just send the specific reason it uninstalled itself. It may be possible to extract something resembling this information from the session log, but I haven't tried yet.

[cjwatson]

The aptitude removal is probably due to C++ ABI transitions: since SONAMEs don't typically capture the C++ ABI, C++ library filenames have to stay the same, but the package name has to change in order that the packaging system knows how (not) to do partial upgrades; this means that we end up with post-transition C++ library packages that conflict with pre-transition ones. Put this together with whoever thought it was a good idea to write package managers in C++, with apt being a little too unwilling to leave broken packages around on the system while their dependencies are being shuffled (although that might not have made a difference - you could still have ended up with aptitude being there but not some of the libraries against which it was linked), and probably with the X.org transition causing the upgrade to fail, and you end up with your mess.

I think the answer is likely to be to simplify the dependency web around aptitude.