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