[Aptitude-devel] Bug#576319: Bug#576319: aptitude: "Cancel pending actions" erase "h - hold" state

[Axel Beckert]

Control: tag -1 + confirmed

Hi,

(I've used moreinfo + confirmed on purpose as I consider this to
indeed be an issue, but it's still unclear how to solve it.)

Manuel A. Fernandez Montecelo wrote:
> >When I set a lower priority version in hold using =, I expect that
> >settig to live future package install actions unless specifically requested to
> >be removed.  Aptitude menu suggest so.
> >
> > "=":          Hold a package in its current version to prevent upgrades.
> > ":":          Keep a package at its current version.  Unlike hold, this
> >               will not prevent future upgrades.
> >
> >But "Actions" -> "Cancel pending actions" reset this frag too.  (The same goes to
> >keep-all for command line. It resets "State: installed [held]" to "State: installed".)
> >
> >This menu entry is frequently used to revert suggested "dependencies" upon
> >starting interactive session or "aptitude install".
> 
> Note that the help that appears in the bottom of the screen when you
> "hover" over that option in the menu is:
> 
>  "Cancel all pending installations, removals, holds, and upgrades."
> 
> I do not have a strong preference, and there is some sense in what you
> say, but it seems that this has been done on purpose and by design.
> 
> (As a data point, I almost never used this option, BTW).

I've been run into this multiple times, too, and I also wondered if
the current behaviour is really that helpful.

> One thing to take into account is that in the command line there are
> ways to mass-apply changes to packages (combinations of hold, unhold,
> keep and keep-all, with patterns).  One can easily apply "keep" (==
> reset pending install/upgrade/removal state) to packages which are not
> already on hold, for example, so avoiding to change the flag of those
> packages.

Since hold is a stonger version of keep, I'd not reset it either.

> But in the UI, I think that there would be no way to reset the hold
> state of all packages on hold, without going one by one and resorting to
> the command line.
> 
> So if we simply change the menu option without offering alternatives,
> maybe some users which already rely on this functionality are not happy.

Yep. I think, we should split it up:

keep  -- reset all install/purge/delete/reinstall scheduled actions
reset -- reset all install/purge/delete/reinstall scheduled action plus hold

It's more difficult in the TUI, though:

Both options should of course show up in the menu.

For the keybindings, I'm indecisive:

My feeling says:

* ":" on a package should reset a "hold".
* ":" on a branch should not reset a "hold".
* This is inconsistent. ;-)

A possible keybinding for "reset" could be ";" (":" without Shift on
US keyboard layout, not yet used), but then again I think that key
combo should be even more harder to type than ":" and not be a single
key strike which can easily be hit unexpectedly.

Looking forward for further comments!

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE