On Wed, 06 Nov 2024 15:59:22 -0700 Soren Stoutner <so...@debian.org> wrote:
> On Wednesday, November 6, 2024 3:06:59 PM MST Aaron Rainbolt wrote: > > And this brings us back to the original idea of creating a > > Weak-Depends field. From my viewpoint, policy states that > > Recommends is for declaring a strong (heavy emphasis on "strong" > > here), but not absolute, dependency. > > After reading over the policy on the subject, I do agree that the > current policy is a little vague as to what is intended. > > "Recommends > > This declares a strong, but not absolute, dependency. > > The Recommends field should list packages that would be found > together with this one in all but unusual installations.” > > https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends > > What constitutes a strong dependency, or what constitutes packages > being found together in all but unusual installations can be > interpreted differently by different people. I would be in favor of > rewording the policy to be more expressly inline with how Recommends > is currently interpreted and used by the majority of maintainers and > users, which is that all packages that are required for expected > functionality should be included in Recommends, even if a feature is > only used by a subset of users. Suggests should be for packages that > enhance some aspect of the program, but which most users would either > not expect to be installed automatically or are so large that a user > should make an explicit decision to install them. I suppose I'd argue that kamera only enhances some aspect of gwenview, but meh, neither of us are really "right" since this is a matter of opinion. It's probably better to look at the practical problems I and the developers of Kicksecure are running into that inspired this thread initially. Kicksecure is a security-focused Debian derivative that is intended to be essentially Debian with every reasonable security hardening feature in existence enabled out of the box. Kicksecure is also used as the base of Whonix, which is intended to provide anonymity features that can be used within virtual machines. We have a number of our own packages that we ship on our images, and we have a number of metapackages that depend on both our own packages and many packages from the Debian repositories. Some of the packages Kicksecure's metapackages depend on are hard dependencies, i.e. if they're removed, the system should be considered broken. On the other hand, many of our packages are ones that we believe should be present on most installations, but that a user may legitimately want rid of. This probably sounds like a good fit for the Depends and Recommends fields of debian/control, since it is, except for one major issue. When we build the Kicksecure images with recommends enabled, they end up with *a lot* of gunk that we don't want. Some packages that end up installed cause actual problems (user can't log in, Debian artwork ends up appearing where it shouldn't, default terminal emulator is hijacked by something called ZuTTY, etc.), other packages simply increase the size of the ISO for no good reason. This is the result of people using the Recommends field the way you're suggesting the policy be changed to explicitly allow. 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. If Debian's packages treated Recommends as "dependencies that are technically removable but you probably shouldn't remove them" for packages other than metapackages, this wouldn't be an issue. That's not possible here though. 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. Aaron [1]: https://github.com/Kicksecure/kicksecure-meta-packages/blob/master/debian/control [2]: https://gist.github.com/ArrayBolt3/1312aa401d0b7ade970210b3f526f9e8#file-kicksecure-metapackage-audit-L54
pgpJ1J1OWozlA.pgp
Description: OpenPGP digital signature
