On 2010-04-03 06:34 +0200, Daniel Burrows wrote: > So, I haven't had time to do actual work on this bug yet, but I've > mulled it over a bit. Here's what I think we know for sure: > > 1) On some people's systems, /usr/bin/aptitude isn't being restored > after the upgrade. > 2) On other people's systems, it is. > 3) I don't know why.
I have some ideas about that: - People who had used an early 0.5 version, reverted to 0.4.11, and still use dpkg 1.14.x with its somewhat buggy update-alternatives implementation could be hit by it. That's not something I would worry much about. - The submitter of #575137 uses btrfs which reportedly may cause severe corruption of dpkg's database and other data: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891 http://kitenet.net/~joey/blog/entry/aloha_btrfs/ > 4) Even if it's available under different names, /usr/bin/aptitude > disappearing is a very unfriendly "user experience". > 5) The problem seems to be related to my attempt to use alternatives > to manage /usr/bin/aptitude. I don't really think so. Well, it may be related but not _caused_ by it. > I liked the idea of using the alternatives system, but it seems too > fragile to be used for aptitude. Rather than trying to put a lot of > effort into tracking down just what's happening, I think it's better to > just back out of using alternatives entirely in favor of something more > robust. With dpkg 1.15, update-alternatives should be robust enough. I would prefer if you could keep it. Running "update-alternatives --display aptitude" in /usr/share/bug/aptitude seems like a good idea to track down future bug reports. Sven -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
