Really unhappy with one dselect behavior...

[Rob Browning <rlb@cs.utexas.edu>]

I normally run dselect every now and then to do my bulk system
upgrading (I use apt for single packages), and there's one thing that
has made me *really* unhappy on several occasions.

Running dselect is (I find) the best way to figure out which new
packages I might want, so I run it now and then and go through the
list of new packages.  However, several times now, I've accidentally
hit return before I was finished going through the list (sometimes
because I got a little confused, and sometimes just inadvertently).
This accident is made more likely by the fact that other programs use
return for much less severe (and reversible) actions.  Like going to
the next line in less or saying "yes, select the current thing" in
other programs.

The big problem is that when you accidentally do hit return, there's
*no* way to recover from the mistake.  The state information about
which packages are new is immediately chunked.  Your only recourses
are to either hope you didn't miss anything important (or anything
that you'd really like), or to allocate an hour or two to go through
the hundreds and hundreds of unselected packages, hoping you can find
any important ones you missed.

Even if you don't accidentally hit the return key, the current
behavior makes it completely impossible to go through the list of new
packages in more than one session.  It's all or nothing.  Once you
enter the "Select" phase, you cannot exit until finishing without
losing all the new package info.

What I'd love to see is, at least, a config option or something that
when active, made dselect ask you for confirmation on leaving the
select screen (before going into final conflict resolution), but
better than that would be to switch things so that dselect doesn't
clobber the list of new packages on "selection" exit, but rather at
the begin of the install run.  This would make it much easier to go
through the new packages in several sittings.

Presuming this isn't just trivial to fix, if I managed to come up with
a patch, would it be likely to be accepted?

Thanks

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930