On Wed, 6 Nov 2024 10:07:54 +0100 David Kalnischkies <[email protected]> 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
