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.
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 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.
A quick review of what I want:
1) All users of an aptitude package should have a working
/usr/bin/aptitude.
2) If aptitude-curses is the only aptitude installed, "aptitude"
should invoke the curses frontend.
3) If aptitude-gtk is installed, "aptitude" should invoke the GTK+
frontend (in the default configuration).
4) It should be possible for users to configure which binary gets
invoked at the system level.
If I want to be more robust by avoiding alternatives, the two obvious
choices I see are dpkg-divert or simply writing a small shell script
that reads /etc/default/aptitude and dispatches using the information
there combined with which packages are currently installed.
I prefer the shell script option for several reasons:
1) It doesn't rely on a slightly obscure part of the packaging system
in its implementation (fewer moving parts => more reliability).
2) It doesn't require me to choose a dummy name to divert
/usr/bin/aptitude to.
3) I can easily make aptitude-gtk and aptitude-curses binaries
available, so tab-completion will show an obvious way to get a
particular frontend.
4) There is no point 4.
5) It's dead simple to implement; the hardest part will be backing
out the alternatives, and it's IMO not a disaster if I that's not
perfect, since only interim unstable/testing users will see this
switchover. (corollary: the time to do this is ASAP)
The only real downside I see is that to attach a debugger to the
system aptitude, you'll need to provide a full path to aptitude-curses
or aptitude-gtk. I can live with that.
Daniel
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
