[Aptitude-devel] Bug#576319: 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