On Sun, Oct 09, 2022 at 10:26:39AM +0800, Paul Wise wrote: > I have often wanted a different kind of relationship between packages > and their dbgsym packages than mere Depends. Currently when a dbgsym is > installed it keeps the library package installed even after it is no > longer used and both should be auto-removed.
I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'. Okay, foo-dbgsym doesn't enhance the functionality of foo directly, but declaring it "enhances default-core-viewer | gdb" is not really a useful remark and surely, like with a "normal" plugin, its usefulness shrinks to fringe use cases without foo being present (at least in the form of a core file produced by it). apt currently doesn't handle Enhances in terms of auto-removal, but I would be willing to change it so that: foo is manually installed: all things enhancing it are not auto-removed. foo is auto-installed: considered for auto-removal if all things enhancing it are also auto-removable (or in other words: foo-dbgsym is manually installed: all things enhanced by it are not auto-removed). That should give you the property that if nothing depends on foo anymore and you don't have anything enhancing it manually installed, it will be auto-removed, while foo and its enhancing foo-dbgsym (or plugin or whatever) stay around as long as foo is still in use – which allows you to set foo-dbgsym to auto-installed after you have it (manually) installed, while e.g. Helmut can install foo-dbgsym without installing a (for him) useless foo keeping it on manual and hence having it stick around. Looking at existing Enhances I can imagine this doing the right thing™ also for more normal plugins and other enhancers: If you want to use emacs mode you have to install a mode – emacs is brought in via a Recommends if its not already there. You can't express that you installed that mode for emacs only. You have to keep it manually installed or otherwise current apt autoremoves it. It also keeps emacs installed even if you later decide its not your thing and apt could autoremove it. With the change above you could set the mode to auto-installed and have apt do its thing after emacs is [auto]removed. Similar, if you install abook to use it from inside mutt, you have to keep it manually installed – which perhaps you want as that is how you manage your adressbock and want to keep it even if mutt is gone, but you can't express the opposite: That you have no need for abook if mutt (or any other thing it might enhance) isn't around anymore. Enhance is mainly used by software centers currently to show plugins and stuff so you can explicitly install it – as in, they will all end up being manually installed. Software centers usually hide things of no interest to casual users, so I am reasonably sure dbgsyms are already hidden (otherwise they would already appear in searches and such). That means that potentially less things are considered for autoremoval with the above change: In the emacs case (and many others) the enhanced foo is not considered for auto-removal due to an existing and already interpreted Depends/Recommends/Suggests, so no change. In the (less common) case¹ of installing abook on its own and having mutt brought in via an unrelated unused dependency chain it would now keep mutt installed as long as abook is considered manually installed. Also, the reverse is true. Keeping "too many" things installed is already a problem as we have no idea if a Recommends/Suggests is really used for anything or if it was brought in for completely unrelated reasons and is now unused (or if it was brought in for unrelated reasons, but the user discovered and heavily uses it via the other tool recommending it). We err on removing "too few" in all those cases as that is usually a much smaller problem in practice, so that doesn't feel like too big of a difference. I left it intentionally open if and who does set foo-dbgsym to auto-installed after it is installed. 'apt install foo-dbgsym' gives you a manually installed foo-dbgsym and you would need to 'apt-mark auto' it afterwards. I think aptitude can do that in one go. I would probably add a way in apt as well (a NeverManual similar to NeverAuto perhaps), but certainly not by default (imagine the emacs example from above, if the enhancer would be set to auto-installed by default and emacs wasn't installed before they would both considered garbage upon install…). On a sidenote: What the Depends ensures which the Enhances doesn't is that they are upgraded in lockstep. As in, if for some reason foo (or foo-dbgsym) have their version appear at different points in the archive apt would hold back on a Depends while with Enhances this dependency would be broken and hence auto-remove kicks in. That might actually be a benefit through as if you remove the debug section from your sources a hold back is not really a good idea. It seldomly is a good idea for various reasons (hence why apt likes to go on a remove spree if that is deemed more beneficial), but that would lead us too far off-topic here… So, could that be an acceptable Option c) ? Best regards David Kalnischkies ¹ this example was explicitly chosen as its possible that you want to use them independently. I don't see a lot of reasons for independent usage of e.g. asc and asc-music even if its of course possible.
signature.asc
Description: PGP signature
