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

[Manuel A. Fernandez Montecelo]

2015-09-20 15:11 Axel Beckert:
>> 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.

(Not because I agree with it, but I post this as further information
about the original intentions, and as a reminder that this sould also be
updated -- as well as the manual, quick help, etc).


I found that it is also documented in the manual, and says:

  http://aptitude.alioth.debian.org/doc/en/ch02s01s02.html

  Actions → Cancel pending actions

  Cancel all pending installations, removals, upgrades, and holds. This
  is equivalent to executing the Keep command on every package in the
  package database.


  http://aptitude.alioth.debian.org/doc/en/ch02s02s03.html#pkgCmdKeep
  

  Keep: Package → Keep (:)

  Flag the current package to be kept at its current version.

  Any action that was to be performed on the package -- installation,
  removal, or upgrade -- is cancelled, and any persistent hold that was
  set on the package is removed.


  Hold: Package → Hold (=)

  Set a persistent hold on the package.

  As with Keep, any action that was to be performed on the package is
  cancelled. In addition, the package will not be automatically upgraded
  [a] until the hold is removed. You may cancel a hold by issuing the
  Install command.

(doesn't mention "Keep" or even "among other options" as a possible way
to cancel it)


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

For me, I think that there's no clear way to tell of the boundary in the
relationship between keeps and holds, as you exemplify with the "this is
inconsistent".

On one hand, we (I assume your position) want a way to reset hold and
expect to use "keep" on an individual level, even if curiously in the
documentation only mentions "install" to reset a hold (it does not, just
applies other action, which might have no effect if there is no
candidate version).

(By the way, it is unfortunate for this case that in aptitude in general
there is no "tradition" that e.g. uppercase reverse lowercase actions.
And it is impossible to stablish by now, with 'c' and 'C' for example.
In any case, "shift+=" is "+", so it wouldn't help in this case.)

On the other hand, we don't want "keep-all" (or pressing ":" on trees)
to remove the holds.  I also think that this is inconsistent, and I am
not very happy about this solution.  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 :-)

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.

  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.

And also inconsistent is that, if keep doesn't mean "unset hold" in the
command line, ":" or Menu-Keep shouldn't do it in interactive mode.  In
which case we would really need a new key to unhold.

Bother :-/


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