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

[Manuel A. Fernandez Montecelo]

2016-01-22 15:07 GMT+00:00 Ralf Jung :
>
>>   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.
>
> I'm not sure I follow. The behavior I would like to see is certainly
> attainable. It can be obtained, for example, as follows (just as a
> sketch, of course, this is not practical):
>
> * Store a list of packages marked as "held"
> * Run the current "Cancel pending actions"
> * Iterate over the stored list, marking every package on it as "held"
>   again
>
> This is entirely local to aptitude, I do not understand how this should
> interact with other tools any more than "Cancel pending actions" already
> does right now.

tl;dr: No, it cannot work properly and interact well with the rest of
the tools without saving the state to places common to other tools at
the time of quitting, not only "local to aptitude".


If one marks a package in aptitude as "held", it has to save it
somewhere (currently to dpkg's database of "hold" packages) so that
dselect or apt or other tools respecting those don't attempt to
install new versions.  This is saved at the same time when one quits
aptitude, because people expect that marking as Hold and
Auto-installed take effect once one quits aptitude or saves the state
in other ways (e.g. after confirming "preview" and before starting
other actions -- removals, or downloads+installations).  I don't know
if all tools respect that yet in all cases, but we've done our bit so
far.  After that point, one cannot "cancel that pending action" --
saving the state makes the action of "set on-hold" as permanent,
having being taken.

Same happens with auto-installed flag, only that this has been going
on since forever (or at least about a decade), not a recent thing like
the holds communicated back to dpkg only in the 0.7 series.

Similar problems *happened* (past, not present) with aptitude not
communicating the status of other actions.  E.g., marking a package to
upgrade in aptitude but not finishing the upgrade and quitting,
removing the package with apt, then firing up aptitude would mark the
package as to be installed.  Many reports about similar sync problems
as well, only addressed in the last few versions.

People expect that all package-management tools in the system
cooperate and don't trip each other.  If aptitude does not save it to
the "common areas" or not at the time of saving the state, people will
start to complain again (as it happened in the past) that actions
selected in aptitude are not respected by other tools, and the other
way around.


That's why the concept of "Cancel pending actions" including scheduled
actions in previous aptitude sessions, doesn't make much sense to me.
The rug can be pulled from below the feet of aptitude by other tools
messing with the system at any time in between invocations, and some
of what aptitude traditionally considered actions (e.g. holds) cannot
be undone.  That's why I said that it's not possible to have good
cooperation with other tools while being able to cancel pending
actions from previous sessions.  And that's why I think that "Cancel
pending actions" only make sense if considering the unsaved state
(i.e., making the previous decisions in this session, *before saving
the state*, be forgotten).


> What I am surprised about is the fact that aptitude treats the "hold"
> bit and the "automatically installed" bit so very different. As a user,
> for me, they are both persistent meta-data that I locally assign to
> packages:
>
> auto-installed = I do not actually want this package itself, please
>   go ahead and remove if it nobody needs it.
> hold = I do not want this package's version to change without manual
>   intervention.
>
> It took me a long time to realize that aptitude, for some (I guess
> historic?) reason, treats "hold" as transient. I do not understand why
> this is done - it makes no sense in my mental model, since transiently
> (i.e., looking at the effect of a single transaction), "hold" and "keep"
> are the same: The transaction *does not* have an effect on this package.

I can only guess that, given the state of the Debian world and the
packaging tools at the time --and probably aptitude was the tool which
introduced the concepts of "hold"--, "hold" was seen as a exceptional
measure to temporarily address problems with packages entering
unstable, and that the natural 

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

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

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

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

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

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

[Manuel A. Fernandez Montecelo]

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 

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

[Ralf Jung]

Hi,

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

Nope, there is nothing broken about the current state of the system when
aptitude comes up with pending actions. I can't reproduce the issue, but
I've seen it happen multiple times that one day, I uninstall something
using "apt remove", and the next day, when I start aptitude, it insists
on installing the package again. Same with me using "apt install", and
then later aptitude wanting to remove it.

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

I'm not sure I follow. The behavior I would like to see is certainly
attainable. It can be obtained, for example, as follows (just as a
sketch, of course, this is not practical):

* Store a list of packages marked as "held"
* Run the current "Cancel pending actions"
* Iterate over the stored list, marking every package on it as "held"
  again

This is entirely local to aptitude, I do not understand how this should
interact with other tools any more than "Cancel pending actions" already
does right now.



What I am surprised about is the fact that aptitude treats the "hold"
bit and the "automatically installed" bit so very different. As a user,
for me, they are both persistent meta-data that I locally assign to
packages:

auto-installed = I do not actually want this package itself, please
  go ahead and remove if it nobody needs it.
hold = I do not want this package's version to change without manual
  intervention.

It took me a long time to realize that aptitude, for some (I guess
historic?) reason, treats "hold" as transient. I do not understand why
this is done - it makes no sense in my mental model, since transiently
(i.e., looking at the effect of a single transaction), "hold" and "keep"
are the same: The transaction *does not* have an effect on this package.

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

Oh, I'm all in favor of hold being integrated with other tools! If I
mark a package as "held" in aptitude, and even "apt upgrade" does not
touch that package, I am happy. (I didn't know this is supposed to work,
will have a closer look at it.) This is yet another reason, actually,
for "Cancel pending actions" *not* to touch the "hold" bit. Again, I
don't see how that interacts with the proposed behavior for "Cancel
pending actions". After all, the "automatically installed" bit is *also*
synced with other tools, and "Cancel pending actions" does not reset
that bit for all packages. Why is "hold" a problem?

Kind regards,
Ralf