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

[Osamu Aoki]

Hi,

On Sun, Sep 20, 2015 at 01:56:29AM +0100, Manuel A. Fernandez Montecelo wrote:
> ...
> 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."

Hmmm... I overlooked this.  Very true. (I saw your another post which
details info from the manual.)

> ...
> 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).

When I was living under the sid system, aptitude started with mass
package removal when some library dependence of Gnome packages were not
optimal when it is started with "aptitude -u" option" or when you hit
"u" to update the package list.  This update action not only downloads
the package list but also update selected packages and suggests package
version updates and removals.

Maybe problem has been tamed by now and you may not be seeing it.

What was needed was a way to get back to the state just after the
package list download but with no auto selected update and removal
choices.  

On Fri, Sep 25, 2015 at 08:01:55PM +0100, Manuel A. Fernandez Montecelo wrote:
> 2015-09-20 15:11 Axel Beckert:
> ...
> I found that it is also documented in the manual, and says:

True.  It is well documented.

>...
> >>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

I was almost bit lost here until I re-read Manuel's summary of the
manual.  My initial reaction was ... My concern was "Action" 
   -> "Update package list"
   -> "something similar to Cancel pending actions"
and get back to keep old "hold" and manually resolve dependency.

But I see this is connected to how "Cancel pending actions" is
implemented.

> ................................. I also don't like to much changing
> current, long-standing and documented practices, unless there is a very
> compelling reason to do so -- you never know when you're breaking
> people's usercases; specially if they went to the problem to read the
> documentation and so on and are relying on this, and there are no easy
> switches to an equivalent solution.  We don't know if there are such
> usecases, that's one of the problems :-)

Yes, it is true that it takes a lot of enery of DDs to change any
behavour of popular programs.
 
> But I also think that we could and could do something about this.
> 
> - Changing the behaviour of "keep-all" is maybe a bit "risky" but its
>  effects on holds seem to be largely undesired/unintuitive, and it is
>  already not documented to remove holds.
> 
>  In the command line, there is an easy workaround to also reset holds
>  if one needs that ("unhold ~ahold"), and we can create a command
>  "unhold-all" if there were many complaints (but I would prefer not to
>  create even more commands, and esp. document and then translate them
>  :-P).  Also, other actions like install/upgrade would reset the hold,
>  so people can get out of it easily.
> 
> - If it works in this way as well (resetting holds), I would like to
>  change the behaviour of "keep" to do the same as "keep-all".  Both
>  should be consistent, and "-all" should be just applying "keep" to all
>  packages, that's all.
> 
> - "Cancel pending actions" is not strongly attached to "keep", so since
>  people are annoyed about the side-effects, we could easily change the
>  behaviour, command description and the documentation... and hope for
>  the best.

Yes.

>  If there are complaints, we can provide "Cancel pending actions,
>  including holds", or "Unhold all packages currently on hold".
> 
> So far is like Axel's proposal, just using concrete and existing names,
> and that maybe we can skip implementing a menu option to unhold-all.
> 
> Does everybody agree on these ones so far?
> 
> 
> But I am still not happy with the shortcuts in the interactive mode,
> because apart from being inconsistent between ":" on individual packages
> and subtrees, it is inconsistent with all of the shortcuts that work in
> the same way.  Except 'F', which I found that it doesn't apply to
> subtrees -- it doesn't make sense in this case, unless the subtree is
> composed by packages from the same source and with the same version.
> (And I don't think that it's as widely used feature as most).
> 
> Perhaps ";" or equivalents in the end is the only solution that we have,
> but I think that we should avoid to add yet another way to do this and
> specially not address the inconsistent behaviour; because people might
> continue to complain that "':' does not work in the same way in
> subtrees!"; and so instead of solving 1 problem we could create 2
> problems.

Alex's proposal of having 2 internal commands is good one.
keep  -- reset all install/purge/delete/reinstall scheduled actions
reset -- reset all install/purge/delete/reinstall scheduled action plus hold

And let "Cancel pending actions" use the "keep" and update documentation
on it.

As for unhold-all, let's make people use existing UI to do that.

How about on TUI, instead of inconsistent behavior:
* press ":" once on the same thing should not reset a "hold". (keep)
* press ":" twice on the same thing should reset a "hold".    (reset)

Shift-: is not ; on German, French, and Japanese keyboard :-) But this
double press approach is common for all.

Osamu