On Wednesday, November 6, 2024 8:12:29 PM MST Aaron Rainbolt wrote: > At this point, we have two options. We can either explicitly remove all > of the extra packages that get installed, or we can skip installing > recommends at all. Both of these come with their own severe > disadvantages. If we manually uninstall everything we don't need, that > means we have to maintain a list of packages that get incorrectly > installed, and keep it up-to-date as package dependencies in the > archive change. On top of that, if a package happens to not uninstall > cleanly, or it otherwise causes problems when installed or uninstalled, > we'd have to figure out how to manually fix that, or avoid letting that > particular package ever get installed in the first place via held > packages or a similar mechanism. This is a rather large amount of work, > and it's not easy to maintain. > > The other option is to skip installing recommends. The reason that > doesn't work well is because if we do that, we can't use recommends in > our metapackages at all - anything we specify as a recommends in the > metapackages won't end up installed. To work around that, we have to > use depends for everything, and to do *that*, we have to basically > reimplement the whole darn recommended packages mechanism in > metapackages. This results in the metapackages setup that we have > today, which can be seen at [1]. There's some "dependencies" packages, > some "recommends" packages, a complex network between the packages to > make things work right, and a smattering of dummy dependencies to allow > users to override certain depends. Our current metapackages scheme has > some rather inconsistent naming and could use a lot of improvement, but > even under ideal conditions (like what I've proposed for Kicksecure in > [2]), this is a lot of ugly hacks that reimplement existing apt > features without using those features just to get around problematic > recommends in Debian's packages. And this is likely *easier* to > maintain than manually uninstalling everything we don't want.
This sounds like exactly the type of work I would expect a derivative distribution to do. If I were in your shoes, I would probably do something like rebuild all packages for my derivative and host them in my own repositories, like Ubuntu does. During that rebuild process, I would use some sort of patch process to alter the Recommends fields to suite the needs of my particular derivative distribution. It would take time to setup and maintain such patches, but that is exactly the type of effort that is required to run a distribution. > So, that's the issue we're having, and the solutions I'm pursuing > (using Recommends differently, adding a Weak-Depends field, or > implementing something like Python's extras like Colin was mentioning) > are things I think would fix the problem for us and others. I'm > definitely open to suggestions for other ways we could avoid these > problems though. This really is the type of problem that needs to be solved inside of your derivative distribution, not in Debian itself, especially in ways that makes Debian worse for its own users or requires a bunch of extra work for Debian's maintainers (like figuring out how to sort all of the Recommends into these new fields/extras options, which different derivatives/users would have distinct opinions about where they should go and would require a lot of time from Debian developers to get each package to a state that would make all potential consumers of the package happy). I am sympathetic to the problems you are having. And I wish you all the best in creating a distribution that meets the needs of your users. Like I said earlier, if there are specific packages that actually have the wrong Recommends, I’m sure the package maintainers would welcome a bug report explaining why a package should be moved to Suggests. But in most cases, what is currently in Recommends is what is in the best interests of Debian users. Unless you can point to a systematic problem with Recommends in Debian (which the examples you have presented so far have not shown), I don’t think upstream Debian is the place to fix the particular needs of your derivative distribution. -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
