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.