Suppose a user wants to install package `foo`. `foo` recommends `bar`.
The user already has an unrelated package `frazzle` installed, which
suggests `bar`. When the user installs `foo`, `bar` will be
automatically pulled in due to the Recommends link. If the user later
uninstalls `foo`, `bar` should become autoremovable, because nothing
has a hard or even strong dependency on `bar` any longer and `bar`
wasn't installed because of `frazzle`.  However, because `frazzle`
suggests `bar`, this will not happen
- `bar` will remain on the system until manually uninstalled.

Steps to reproduce:

1. Ensure `git` is installed by running `sudo apt install git`.
2. Create a testing metapackage called `test-meta`, which recommends
   `gitk`. My source package tree looks like this:

test-meta (dir)
|
-> debian (dir)
   |
   -> changelog (file)
   -> control (file)
   -> rules (file)
   -> source (dir)
      |
      -> format (file)

test-meta/debian/changelog:

    test-meta (1.0) unstable; urgency=medium

      * Test build

Am Wed, Nov 06, 2024 at 01:59:59AM -0600, schrieb Aaron Rainbolt:
the user has realistically only interacted with test-meta in that time
frame. The longer the time is between these two steps through it becomes
possible that the user discovered gitk and fell in love with it.

autoremoving it would be very wrong then (and gitk is a really bad
example here as you interact with it directly; many recommends "just"
enable features within the package that recommended them).


Thankfully, we don't need to debate how many minutes have to be between
the two to behave one way or the other.

1. If you dislike the behavior for Suggests entirely, disable it:
  APT::AutoRemove::SuggestsImportant "false";

2. Your step 5. would be better expressed as a sort-of 'undo'. There
   exists requests for it, some pre requirements (like history.log),
   "all" that is missing is the actual code of course.

3. Instead of trying to track which packages caused which other packages
   to install¹ you might be better off with given the user a chance to
   say: "git was suggesting gitk, but I resisted." to ignore that
   relation (instead of the global switch from 1.). Does not exist in
   apt and I think it shouldn't as it is too needy and kinda needs
   a dedicated front end for the constant user interaction.

4. Its important to remember that autoremove is not meant to help you
   maintain a lean and clean system. It is trying to remove "obvious"
   obsolete stuff, but if it can't decide, it will always opt for keep
   because user attention, knowledge and time is limited, but disk space
   usually isn't ~ in the general case at least.


¹ Lets say: pkga recommends foo, pkgb suggests foo. You install pkga
(which also brings in foo). After a while you install pkgb and use it
– especially that feature only enabled by foo, but how do you know that.
Six months later you remove pkga. Are we autoremoving foo now?
It was never installed due to pkgb, it was already there.
How about if pkga is replaced in an upgrade with pkgc that doesn't
recommend foo? What if we don't deal with 3 but 300 packages?


So, in short: I think your suggestion is over-fitted for your example
and I believe your example would be better served by 2. for which
bug reports already exist, so adding another doesn't help & I am
therefore closing this one (as sorta duplicate).


Best regards

David Kalnischkies

Hmm, didn't know that existed. I wonder how that interacts with
`--install-suggests`, though I suppose it doesn't matter since someone
who toggled that feature on should probably expect things to be
autoremoved if they don't take explicit measures to keep them.

Respectfully, this isn't at all helpful here. The actual use case I had
in mind for fixing this issue would be to prevent situations where a
downstream derivative's metapackage changes the applications it
recommends (for instance to install the Chromium web browser instead of
Firefox, or to change one text editor for another, or something like
that). The preferred behavior in these instances is that the new
package should replace the old one (which will get autoremoved by the
user whenever they care to run an autoremove operation, unless they
mark it as manually installed in order to keep it). Being able to undo
an apt operation doesn't help at all. I see why you thought this would
help since my minimal reproducible example made it look like that, but
my example was meant to demonstrate the issue, *not* the use case
scenario.

Not a bad idea, definitely feasible.

Sure, but keep in mind that I'm willing to contribute code to fix the
"bug" I'm looking at. Perhaps the existing developers haven't found
something like this worth implementing, but I think it's worth it and
am willing to do it, depending on how big of a job it becomes.

This is a good point. Arguably though, autoremove already does lots of
surprising things if you don't look at the packages it's going to
remove. (Install, full-upgrade, remove, and purge do too in some
instances.) Autoremove's job is to clear out unneeded junk, and the
only way it knows how to do that is from package dependencies and
stored data about how packages were installed. Figuring out the user's
use case is not its job, that's the user's job and it's why apt shows
info about what packages will be installed, removed, etc. (I realize
typing this that this isn't a great argument though, everyone knows
that users can and will blindly hit `y` whenever prompted by apt, and
it's already liable to eat people's face off when they do that. Making
that worse is potentially not a great idea, though I'm not sure that
autoremoving foo in the scenario you mention makes things that much
worse from that standpoint.)

As explained above, your suggestion in 2 is not really usable or
relevant here. It only really fits the particular example I made here,
not the actual use case. It seems you didn't actually close the bug, so
there's nothing further for me to do to reopen it, but please do not
close it yet.

I agree that autoremoving gitk in step 6 would be wrong.

However, what about `sudo apt purge --autoremove test-meta`? As I
understand it, that currently has the same effect as `sudo apt purge
gitk` followed by a separate `autoremove`; but would it be possible
for the `--autoremove` flag to instead mean “auto-remove packages that
are made autoremovable as a result of removing test-meta”? In effect,
something like “determine the list of currently auto-removable
packages”, “remove test-meta”, “remove any packages that are now
auto-removable but weren’t before the test-meta removal”.

With that change, setting SuggestsImportant to false temporarily would
allow the example installation to be reversed.

Regards,

Stephen