On Wed, 06 Nov 2024 21:41:43 -0700 Soren Stoutner <so...@debian.org> wrote:
> 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. I'm not sure why this would be a reasonable solution here. Kicksecure already has a solution that is working. We dislike it, and I'd like for something better to exist, but our metapackage tricks work for the time being. To be clear, I am not just doing this because I have a job to do and this is part of it. I'm doing this because I truly believe that Debian's current "recommended bloat" issues are a problem within Debian itself and are worth my time and effort to solve. With that in mind, bringing into the picture what a derivative should or shouldn't do isn't really relevant to the discussion at hand. Much like the diffoscope example, Kicksecure's issues were intended to be an example, not a definition of an end goal. > > 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). There's no reason this exact issue couldn't happen in Debian itself. Any metapackage system that encourages its users to use --no-install-recommends to avoid installation of unnecessary packages is going to run into the exact same problem, whether inside of Debian or outside of it. For that matter, any Debian user who uses --no-install-recommends with a metapackage that uses Recommends is going to run into the same kind of problem. > 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. Again, this isn't a problem limited to a derivative distribution. I respect that your opinion of how Recommends should work differs from mine. That doesn't change the policy though, and it doesn't change that neglecting or changing the policy's rules in this area will cause and is causing problems to some of Debian's users. Ultimately I don't care exactly how those problems are solved, I just want to solve them. In case it's helpful to know, I do *not* want to make Debian worse. A solution that makes Debian worse is not a solution at all since the primary goal of my endeavor here is to make Debian better for everyone. The issues you've mentioned with some of my suggestions are real, and you may notice I actually agree with you about the need for a less strict Recommends. It's important to me though that if Recommends is to become formally less strict, that something step in to replace it and act as a strict optional dependency specifier. Colin's idea seems to be the most promising in this area so far, and I'll probably try to implement a prototype of it once the ideas have some time to develop a bit more. Aaron
pgpDZgIjaCtj6.pgp
Description: OpenPGP digital signature
