[Aptitude-devel] Bug#576319: 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 <post at ralfj.de>:
>
>>   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 state of any package is to not be on
hold -- that's why "keep" et. all reset the "hold" state.

I think that this still applies nowadays, hold should be done very
rarely, not for many packages and not for a long time, otherwise one
can miss crucial security upgrades or similar.


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

It should work since a few versions ago.


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

I think that you misunderstood my message.

The main complaint of this report was that "Cancel pending actions"
unholds packages, and I was proposing to solve it by "Cancel pending
actions" only ignoring the actions taken in the current aptitude
session (this includes ignoring "holds" set so far in the current
session, but not in previous sessions).  That was my example #1 in the
previous message, and I don't want "Cancel pending actions" to
continue to unhold all packages, which is what currently happens
(example #2).

Setting packages on "hold", or marking them as to be "purged" etc.,
has to be saved and communicated to other tools when aptitude quits,
at which point cancelling those previously scheduled actions (my
example #3) is not [always] possible, which was Axel point based on
your use-case/reply to my message.  And in particular, "holds" are not
a scheduled action like others -- once saved, one doesn't know if it
comes from the last session or from very long ago or from other tools.


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