Bug#1086801: apt: autoremove fails to remove garbage packages with unrelated Suggests links
On Wed, 6 Nov 2024 10:07:54 +0100
David Kalnischkies <david@kalnischkies.de> wrote:
> Am Wed, Nov 06, 2024 at 01:59:59AM -0600, schrieb Aaron Rainbolt:
> > 4. Install the package with `sudo apt install
> > ./test-meta_1.0_all.deb`. 5. Purge the package with `sudo apt purge
> > test-meta`. 6. Run `sudo apt autopurge`.
> >
> > Expected result: `gitk` should be removed during the autopurge step.
> >
> > Actual result: Only the test-meta package is removed.
>
> That might be expected if there are mere seconds between step 4 and 5
> as 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";
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.
> 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.
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.
> 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.
Not a bad idea, definitely feasible.
> 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.
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.
> ¹ 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?
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.)
> 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).
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.
> Best regards
>
> David Kalnischkies
Reply to: