On Thu, 7 Nov 2024 19:53:27 +0000 Roger Lynn <ro...@rilynn.me.uk> wrote:
> On 06/11/2024 19:20, Bill Allombert wrote: > > Le Tue, Nov 05, 2024 at 05:35:59PM -0600, Aaron Rainbolt a écrit : > >> Hello, and thanks for your time. > >> > >> I've been a Debian user and contributor for a while, and have > >> noticed a rather frustrating issue that I'm interested in > >> potentially contributing code to fix. The issue is what I call > >> "Recommended bloat", which in short is what happens when you > >> install a package with all of its recommended packages, and end up > >> with a whole lot of stuff installed that you don't want and that > >> the package you actually wanted probably didn't even need. > > > > A proposal I made was an option for apt to handle Recommends non > > recursively. > > That is if A Recommends B and B Recommends C, > > apt-get install A --no-transitive-recommends > > would install B but not C. > > This, please! > > As a user, when I choose to install a package, I am likely to have a > reasonable idea of what that package's recommendations do and whether > I need them. However, for transitive recommendations, it is unlikely > that I will know whether I need those packages. If they in turn have > lots of further dependencies then I will probably not install them > and take the risk of unwanted breakage to my system. If the top level > package that I originally did want needs those transitive > recommendations it should recommend them itself, rather than relying > on recommendations further down the dependency chain. One issue with this is that it doesn't really work if you're dealing with metapackages that in turn reference other metapackages. You end up with the "lower" metapackages installed but all of their recommends missing. Making it possible to tune the number of "levels" apt digs would make something like this more useful, but it's still possible for there to be a "lopsided" network of metapackages, where installing recommends to level N results in a metapackage's recommends being omitted, but installing recommends to level N+1 results in a non-metapackage's recommends being installed. However, this isn't that hard to rectify - rather than specifying the depth at which apt should stop installing recommends, one can specify the packages in the dependency tree from which apt should install recommends from. I.e., to replicate --no-transitive-recommends, one would do `sudo apt install package --only-install-recommends-from=package` (please someone pick a better name for this switch). If you're installing a complex metapackage network, you can just specify all the metapackages you want to allow recommends from, i.e. `sudo apt install metapackage --only-install-recommends-from=metapackage,submetapackage1,...` This could then be used in combination with per-install package blacklisting (i.e., `sudo apt install gwenview+ kamera-`) to control recommends very easily and without much effort. As for Kicksecure, it would solve the problems we're running into perfectly, since we'd be able to use recommends in our metapackages and get the advantages of skipping them for normal packages. No changes needed to Debian policy. No changes needed to debian/control. Just modifying apt is enough to begin with, and might even be enough in the long run. This wouldn't fix the issue of packages having too much in their Recommends, but that can be handled with bug reports. Aaron > It would also be helpful if more package descriptions could explain > why recommended and suggested packages are needed or helpful and what > functionality they provide that would be lost if they were not > installed. (Many already do this.) > > Thanks, > > Roger > > PS. I use aptitude, so I can interactively browse through the lists of > recommendations, but it's still hard work and it can be a long list > of very obscure packages. Do any of the GUI package managers show a > graphical dependency tree? That might be really helpful to understand > the package relationships and visualise the consequences of various > actions. > > PPS. And the moon on a stick too, please! >
pgpVQPIkiT_dZ.pgp
Description: OpenPGP digital signature
