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

Fri Jan 22 14:26:49 UTC 2016

Hi,

2016-01-22 09:03 Axel Beckert:
>Hi,
>
>Ralf Jung wrote:
>> > I am going to fix this by making "Cancel pending actions" to reload the
>> > cache, which is roughly equivalent to restart the program without
>> > exiting and starting again (effectively forgetting all what was marked
>> > in this session).
>> >
>> > I think that this is more consistent with "Cancel pending actions" as
>> > described by the original report and other users, than the previous
>> > behaviour -- removing all holds and auto-installed flags of all packages
>> > in the system, even if they had not been changed in this session.
>>
>> Does this mean that if there is an action stored in the cache, that
>> action would not be canceled? I think that would also be confusing.
>
>I agree with Ralf here. Cancel pending actions should also cancel all
>scheduled actions which have been scheduled in previous aptitude runs,
>too.

It looks to me that different people have different ideas in mind about
how it should work, incompatible between them:

1) One is to discard pending actions of the current session, considering
   actions previously scheduled (and saved) and not as "pending [to
   save/confirm]", but as "confirmed that I want to go ahead with
   those".

   This, intuitively, is what makes more sense to me, that's why I was
   going to fix it in this way and I thought that it was
   uncontroversial.

   There's no current way to achieve this, other than by quitting
   without saving the state (Control-C, unadvisable in general) plus
   starting again or Undo-ing one by one all previous actions in the
   section.  I'd maintain that this is a more
   useful/requested/commonly-used feature than reverting previously
   confirmed and saved states.

2) Another is to reset all packages's states to "keep", removing holds
   and sometimes auto flags, which is what it is currently doing.

   This was done intentionally in this way --and documented-- because
   "hold" (and I guess that "auto installed" as well, but it doesn't
   make much sense in this case) was considered a kind of transient flag
   that should not be present in a normal state of the system, thus
   "hold" was considered to be a "pending action" in the same way as
   "upgrade", "install" or "remove".

   What people were complaining about in these bug reports (#537735,
   #576319; and probably others where people complain about the loss of
   Hold or Auto without having founding out the cause) is essentially
   that "Cancel pending actions" is removing a property that they don't
   consider "pending" or transient, but permanent (auto-installed and
   holds).

   Even without "Cancel pending options" working in this way, the
   actions which haven't taken place, can be easily reverted by applying
   "keep" on the group of packages that change (searchable with
   "!~akeep", for example, or going to the "preview" screen and undoing
   that), and perhaps selectively (not cancel all actions at the same
   time, but only a subset).

3) Another, what Ralf and you are requesting, is to cancel not only
   actions pending in this session, but previously confirmed by saving
   them in previous sessions.

   (Actually, it looks to me that Ralf is experiencing some other
   problem, because it is not normal that aptitude often wants to change
   the current state of the system the first time that he fires aptitude
   up -- that's because it detects some conflict or brokenness with the
   current state.  Ralf doesn't like the current behaviour #2 either).

   This is fundamentally unattaintable.  Actions are immediately saved
   to several places, including apt and dpkg accessible files, so if you
   mark a package for deletion and quit aptitude, "dpkg --pending
   --remove" will remove it.  If apt, dpkg or other tools install other
   packages in the meantime, or update the available packages, upon
   starting aptitude it will re-read the state of the system and will
   update things accordingly, removing/invalidating part of the
   previously scheduled actions.  So one will be unable to undo some of
   the "saved but not performed actions [within aptitude]", because
   actions would have been performed outside of aptitude.

   Additionally, there are many other details to sort out in that case.
   "On hold" would never be able to be considered as a "pending action"
   (even if it's always described as an action in the doc), and if a
   package previously marked as "install" and one does "keep" it in the
   current session, "Cancel pending actions" will not set it as
   installable in any case.  In short, the only way to implement this is
   basically how it already works, #2.

   Same as with #2, even without "Cancel pending options" working in
   this way it's possible and easy to revert these actions, so I don't
   think that losing this way to achieve a purpose is a deal-breaker.

So, for me, #3 is not the way to go, and it's a fundamentally flawed
approach (it will never work as intended, as long as aptitude cooperates
with other tools of the ecosystem and doesn't override their actions).

As Maggie and others would have it, There is No Alternative [1].
There's no way but to continue in the path of the integration with other
tools of the Debian package ecosystem, because some of this was
requested since the early days of aptitude back in 2000
(e.g. integration of Holds with apt and dpkg, and only fixed in the
recent 0.7 series), and because saving this information in places
accesible to apt and dpkg is the only sensible way to do it.

  [1] https://en.wikipedia.org/wiki/There_is_no_alternative

#2 is what happens now, which doesn't leave people happy, as we've seen
in these reports (and the complaints that "keep" also reset holds).

If we're to keep something like #3, I'd say that we should rename it to
the current #2 "keep all", probably removing holds and all.

#1 (in the form of "Cancel pending actions" as described in #1, or other
possible names such as "Undo all", or "Reset/restart session") is a
missing feature that I want to implement, and I'd argue that what most
people really think that they will achieve when invoking "Cancel pending
actions".

>I'm though not sure if by "cache" you mean apt's cache (which would
>include holds, but not aptitude's scheduled actions) or aptitude's
>extended states file (which would include both).

I mean the same effect as restarting aptitude -- which includes apt
cache plus aptitude bits of data.

>In the latter case, please note that such things happen as
>
>1. Start TUI
>2. Schedule some actions
>3. gg -> Start downloading files -- this saves the extended states
>4. q -> Abort download
>5. Cancel pending actions

As I explained above, this has never worked properly to restore previous
states, and cannot be made to work to reliably rever all actions taken.

"Cancel pending actions" is just a "keep-all" removing holds, equivalent
to press ":" in Upgradable + Installed + NotInstalled subtrees.

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