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

[Manuel A. Fernandez Montecelo]

2015-09-25 12:11 Ralf Jung:
>Hi,
>
>Wow, finally I know what has been causing all that frustration over the
>years! I have been hit time and time again by the problem that aptitude
>kept forgetting which packages I had on hold. Recently, while the gcc5
>transition was being staged and I had >100 packages on hold, that was
>really annoying. When aptitude forgot (again) all the things I told it,
>it took me minutes to get all the packages I wanted on hold back to that
>state.
>
>It never occurred to me that "Cancel pending updates" could reset the
>hold state. Admittedly, I didn't read the description at the bottom, but
>the menu entry is IMHO pretty clear: Having a package on hold is a
>fairly permanent state, similar to the "automatically installed" bit. I
>frequently use "Cancel pending actions" to get aptitude back into a sane
>state, when it selected a strange set of updates or otherwise dragged
>itself into some bad corner.

It's funny how Axel, you and other people use that frequently; but I
almost never use it and always use Undo.  Maybe it's because I usually
cherry-pick updates rather than wholesale, so I go step by step and
there Undo is more useful.

I think that it's usually usually safer to use Undo for the time being
even for wholesale operations, though.


>IMHO, having "Cancel pending updates" affect the hold bit is just as
>surprising as if it would affect the "automatically installed" bit. I
>expected it to act as if I would manually have selected "Keep" on every
>single package. Now, I just noticed that "keep" also clears the hold
>bit. I don't understand this, either: The description says "Cancel any
>action on the package". But "hold" is not an action; it is a state -
>just like "automatically installed" is. It means "please don't update
>this package, ever", similar to how "automatically installed" means
>"please uninstall this package when nobody depends on it anymore".
>Again, why does "keep" reset one part of the state, but not the other?

No idea.  Knowing other cases in which surprising behaviour happened,
there usually is/was a good explanation for it, whether you agree with
the original developer or not.


>And finally, regarding the functionality that's lost when "Cancel
>pending actions" no longer reset the hold bit: First of all, I have a
>hard time imagining a situation where I would want to wholesale reset
>the hold bit of all packages; similar to how the situation in which
>you'd want to reset the "automatically installed" bit of every package
>is IMHO rare.

I can imagine a situation in which you use unstable, and have some
packages on hold scattered over many sections in the default view
(e.g. parts of KDE, GNOME or some other big collections of related
packages) because you are scared of the upgrade or it's half-broken for
weeks, and then you unhold them at once when you are ready to upgrade.

Or the same with stable and testing, perhaps testing with higher
priority but wanting to keep some subset of packages in unstable, and
then upgrading all of them together when a new release is out.

I don't think that it's a terribly popular use-case, but hey...

And I cannot imagine scenarios wanting to clear "automatically
installed" so easily, no.


So anyway, let's see.  It looks like it's better to not touch holds when
clearing pending actions, but I don't know how difficult it is because
from fixing a few similar issues recently, sometimes the code is very
entangled and it takes days or more than a week to get to a proper fix,
even if in the end the changes amount a handful lines of lines changed,
or less.


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