On 2020-06-04 at 10:30, David Wright wrote: > On Mon 01 Jun 2020 at 12:15:02 (+0200), Marco Möller wrote: >> The short answer to this thread is that unfortunately Debian is >> not prepared with a simple solution for this simple task, but >> sophisticated workarounds are needed. > > As has been explained, it's not so simple, because *your* focus is > solely on the last apt command that you typed, whereas the package > management system is concerned with the whole system. Apt deals with > the system as a current state, and not as a chance sequence of > commands in reaching that state which must be reversible and > replayable, back and forth. > > When you install some packages and change your mind, just copy and > paste the line from /var/log/apt/history.log, replacing install with > remove (or purge). Sophisticated? Doesn't that fail to address the exact Recommends-related scenario which was his original complaint? Say A and B both recommend C, and no other relevant packages do. Then: $ apt-get install --no-install-recommends A $ apt-get install B $ apt-get purge B $ apt-get autoremove As I recall and understand it, his original complaint is that this will then leave C installed, even though the context for the permission for it to be installed (the installation of B) no longer applies. (Similarly if you install A after installing B but before the autoremove.) By contrast, $ apt-get install B $ apt-get purge B $ apt-get autoremove $ apt-get install --no-install-recommends A will leave C not installed. He appears to argue (if not all that clearly) that the package manager should be tracking "install Recommends?" status on a per-package basis (i.e., probably in /var/lib/dpkg/status), such that only packages for which that flag is true will be considered as preventing a Recommended package from being autoremoved, even when Recommends are configured to be important. This would then let those two scenarios produce the same result, which could be argued to be valuable for "least surprise" consistency reasons. Given the existence of the ability to configure Suggests as important, presumably an analogous flag would then need to be tracked per-package for Suggests as well. Structurally this doesn't even seem too difficult to design, at a naive outsider's glance, but how practical it would be to implement - both in terms of code, and in terms of the data that would have to be tracked and stored, as well as in terms of implementing both on top of the existing stored data which does not track this - may be quite another story. It gets trickier again when you start to consider more complex scenarios, such as what happens when you change the "install Recommends?" status for an installed-as-Recommends package later on. When you install A with --no-install-recommends, C would clearly get that status set to "false". But when you install B without that switch, should C's "install Recommends?" status change to "true"? If the answer is yes, then the problem he was complaining about returns. But if the answer is no, then if you later remove A, C is now in a different status from what you'd have gotten if you installed B (and its Recommends) without having ever installed A in the first place. I don't see as simple or straightforward a way to design around that problem. At that point, I think you would indeed have to start tracking the installation history in tree fashion, and I don't even know what the data structures or the necessary stored data for handling that elegantly or cleanly would need to look like. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature