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

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


2010-04-03 04:09 Osamu Aoki:
>Package: aptitude
>Version: 0.6.1.5-3
>Severity: normal
>
>I am not C++ coder but src/cmdline/cmdline_do_action.cc line 299 is where
>problem comes from.
>
>Please read on.
>
>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).


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.

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.


There are many angles to consider to this question, so it will require
some thought, and review many other bug reports that have requests about
holds first.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>