Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
As I indicated in a recent message, I don't currently have time to
get aptitude working the way I'd like. Please consider this a public
call for a codeveloper -- you can "interview" by submitting working
patches for one of the issues below, particularly the ones I've outlined
a fix for. (aptitude is maintained as an Alioth project, so if you have
an Alioth account, I can just add you to the project)
I've added notes on immediate and long-term solutions to some of these
issues below, tagged as [development note]. If no-one takes me up on
this, which history would indicate is likely, this will make a nice TODO
list anyway :)
On Thu, Oct 02, 2003 at 07:43:37PM -0400, Nathanael Nerode <neroden@twcny.rr.com> was heard to say:
> Although aptitude uses only one fewer line of screen space for the
> list of packages, somehow it manages to have less information. The
> absence of priority information is unpleasant to say the least.
Priority information isn't shown because I felt it would clutter up
the screen, and I for one never used that information anyway. It will
never be visible by default.
> In trying to get it to show priorities, I discovered that the options for
> changing display formats are completely cryptic; on
> my machine I see:
> The default grouping method for pacakge viewsr)
The r) should be a different color than the rest, which is why I've
never noticed this on my computer. I suspect you're using a less
featureful terminal than standard xterm?
[development note]
In any event, this table needs some padding between the two columns.
This is a fairly simple fix, unless I forgot to implement inter-column
padding in vs_table, in which case it needs to be hacked in first.
> The default display-limit for package views
> The display format for package views %c%a%M %p #%v%V
> The display format for the status line %d
> The display format for the header line %N %n #%B %u %o
[development note]
This is a nice general method of configuration, but for many tasks
something like this would be better:
View->
Show/Hide column->
[X] Action
[X] Package name
...
An interesting problem would be to merge the two methods of
configuration. The current method is much more flexible, but the design
makes it hard to reliably configure the columns based on a bunch of
boolean variables. A new design or design changemight be needed: for
instance, only allow one column of each type (which makes some sense
anyway) and store a boolean vector indicating which columns are active.
> When packages are selected to be installed "by default" as the
> result of a manually selected package, I get to see and adjust the list
> before going ahead with the download & install. Unfortunately, I *don't*
> get to see whether the packages are being selected because they are actually
> depended upon, or whether they're "Recommended", or whether they're
> "Suggested".
[development note]
Code to determine this is in cmdline.cc. To move it to the UI:
(a) move it somewhere under generic/
(b) figure out how to put its output into the preview screen.
A reasonable first try is to put it in the lower half of the
screen, where the package description is by default.
One approach to this is to make the lower half of the screen
switchable (using a vs_multiplexer) and to bind some key to switch
it. I think this may already be done in order to allow tag
databases to be edited.
Then, add a new page to the multiplexer which is visible by
default and shows extended information about why the currently
selected package is in its current state. This infrastructure
could also be used to show package info in the lower half like
dselect does, eventually (but maybe a modifiable form like the
aptitude info screen)
See how package descriptions work in the code for more
information.
> There's no easy way to get the dselect behavior of "These are recommended,
> these are suggested. Which do you want?" -- which is what I like.
[development note]
It might be a good idea to add a tree for suggested but not selected
packages to the preview screen. This tree should be collapsed by
default.
> Figuring out how to tell aptitude not to automatically delete "unused" packages
> required reading the User Manual while knowing that this was an issue.
>
> This is on by default, and the information about marking a package
> "manually selected" or not does not immediately spring to mind as having
> anything to do with whether a package is "unused" or not.
>
> Perhaps if it said "Remove unused automatically-installed packages
> automatically" ? ;-)
In most cases, the garbage collection should operate without you
needing to know about it. (the increasing prevalence of meta-packages
is making this a bit tricky -- some explicit marking of these beasts in
the package tags might be nice)
If you have a problem, it's likely because something was removed that
you didn't want removed, and the preview screen contains an explanation
of why it's being removed. It should also contain a message about how to
stop similar packages from being removed in the future, but I'm not sure
if it actually does. That message could perhaps be made more explicit.
> The Users Manual starts with a section on the non-interactive interface.
> Huh?
I suppose the command-line interface could be documented later, but
it's usually documented earlier. Or are you objecting to the odd phrase
"non-interactive interface"? I guess it is a bit odd. "non-visual"
interface might be better, but I refuse to say "non-GUI", because it's
not a GUI durnit! "command-line" is most accurate, but most people
would think this just means it runs from the command-line; it actually
includes a (primitive) command-line as well.
[development note] While I'm thinking about the internal command-line,
there is a whole raft of annoying behaviors involving it that could
stand to be sorted out.
> Upon hitting 'g' without having done much, aptitude blanked out both sections
> of the screen mysteriously. I eventually figured out that I needed to
> go to 'Views' and pick 'Next'. Huh?
[development note]
If it is still empty after all packages have been processed,
pkg_grouppolicy_mode should add a child to its tree which explains that
nothing is to be done.
This requires adding a new virtual method to the base group policy
class which is called after all packages have been added.
> Under "Tasks", if 'tasksel' is uninstalled, the one and only subcategory is
> "Unrecognized tasks". Huh?
There's task information in the database, but no mapping to
"human-readable" names. Would you prefer that tasks be hidden entirely?
> The menu is critical to dealing with many of aptitude's, um, issues.
> However, you have to hit F10 to get it. Which is usually OK, but if you're
> connected through ssh from something which can't do better than a vt100
> terminal, you're screwed.
Escape or Control-Space should also work.
> 2. "Remove unused packages automatically" is (a) better described and
> (b) off by default.
It will never be off by default while I am a maintainer of the package,
unless someone gets me to change my mind (which I don't think is likely;
I already thought for a while about this before changing the default to
be "on")
[development note]
Here are my top issues with the program:
(a) Some things about changing the mode of a package are really
broken. An honest-to-goodness FSA of package states and possible
transitions needs to be drawn, because it's become clear that doing
this in an ad-hoc way is just not working.
The following states have to be kept in sync:
(1) aptitude's information about what to do with a package.
(2) aptitude's information about whether a package was installed
manually.
(3) dpkg/dselect's information about the state of a package and what to
do with it. This is read-only from aptitude, but changes to it
should propagate to aptitude. (especially changes in installed
state, to prevent aptitude from removing new packages or
installing removed packages)
The biggest problem is that (1) and (2) get out of sync, or are
changed in inconvenient ways. The big one here is that packages
should only be marked as "automatic" when initially installed. ie,
removing a hold from an automatic package shouldn't make it manual
(fairly easy to fix). However, there are a few other issues that I
run into from time to time.
Sometimes I also see (1) and (3) out of sync, and I'm not sure why.
Debugging is needed here -- or, as I said, an FSA that can be analyzed
and/or converted into code.
(b) aptitude should not upgrade packages by default; it causes too
many problems.
(c) In the same vein, aptitude should be cleverer about fixing broken
packages. It has too strong a tendency to remove stuff. Some
squinting at apt library calls may be necessary here.
(d) aptitude needs to provide better information about broken
dependencies. Tracking back to "why was this automatically
installed", I suggest something similar to what dselect does,
implemented using the multiplexer there.
You could even use the same code as for the "installed state
explanation" stuff, but you would have to fix the detection of why
a broken package is broken (in the cmdline.cc stuff) -- it seems
to have issues right now.
(e) I'd like a menu for actions on the current package. (install,
remove, etc) There are some structural issues that make this
nontrivial, but I think they could be fixed or worked around with
a little ingenuity. (one `workaround', maybe a solution: catch
the pkg_selected signal from the tree store that value somewhere.
Use it to decode what to apply signals to. Another, more
complicated but more general approach, is to add the notion of
a "selection" to vs_tree. Probably this would involve a template
parameter: the type of object being selected.
Other code changes that would be nice, but are not IMO essential to
fixing currently obnoxious bugs:
(a) I spent some time using doxygen over the summer, and it's quite
nice. Documenting some of aptitude's internal APIs might make it
less intimidating for other people to work on the project. Or
maybe this is just wishful thinking.
(b) Tagging packages, operations on tagged packages: probably not too
tricky, and not too useful most of the time, but a nice touch.
(c) I still think there should be a less ugly way to do what vs_tree
does, but I haven't found it yet.
(d) It might be possible to make the info screen better by making it
something other than a tree. I'm not sure; this is something to
think about for a while before doing anything.
(e) I've heard about a "debtags" database system that's trying to
find a general solution to the problem of categorizing packages.
I took a look at their library at one point and wasn't able to
figure out how to use it, but if this project is still going
somewhere, supporting it in aptitude would be nice.
(f) Oh yeah, the existing category browser is really unstable.
(g) Some canned organizations (sorting/grouping mode) would be nice.
(h) ummm, I can't think of anything else right now.
Daniel
--
/-------------------- Daniel Burrows <dburrows@debian.org> -------------------\
| "A game which, from the viewpoint of the other players (ie, everyone) might |
| be compared to playing poker with blank cards, for infinite stakes, with a |
| Dealer who won't tell you the rules and who /smiles all the time/." |
| -- Terry Pratchett, _Good Omens_ |
\---- Be like the kid in the movie! Play chess! -- http://www.uschess.org ---/
Reply to: