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.montez...@gmail.com>
