[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Return a Debian system to a pristine state

On 04.06.20 21:46, The Wanderer wrote:
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

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.

Thank You! You perfectly understood me and put it into clear words.

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

  > 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.

Because of this more complex scenario I suspected that not simply a flag might suffice and therefore suggested that a tracking list would be needed for registering exactly by WHICH other package a certain package became recommended and drawn in. This list would get longer if more than one package would have asked for the recommended, certain package, and if this certain package specific list would result empty again then this would flag it for allowed autoremoval. Of course the certain package should not be an essential package like installed during the intial Debian installation, but this requirement is what the current apt is already considering for all packages anyway.

After your post nicely confirmed that my idea was perfectly understood, I will leave it here in the thread as it is. In the near future I will organize my words, probably copying some of the statements from this thread, and send it as a feature request to the apt developers. I think there is not more which we can do as simple users at this point.

Best wishes, Marco!

Reply to: