On Wed, 06 Nov 2024 14:21:30 -0700 Soren Stoutner <so...@debian.org> wrote:
> On Wednesday, November 6, 2024 12:08:07 PM MST Aaron Rainbolt wrote: > >For instance, gwenview currently > > recommends kamera. gwenview is an image viewer, kamera is a tool for > > working with digital cameras. Now it is true that kamera enhances > > gwenview's functionality by allowing it to see pictures on a digital > > camera that is plugged into the system, but by no means is gwenview > > useless or even substantially degraded from a functionality > > standpoint when kamera is missing. > > In my opinion, gwenview recomminding kamara is the correct behavior > and inline with policy. > > If I install an app, Recommends should pull in everything that would > make all the buttons in the GUI work correctly. I shouldn’t have to > manually install anything else for them to work. Kamera should > definitely be in Recommends for gwenview (although not in depends). > > If you don’t want that, set your system to not automatically install > recommended packages, and then you can manually install whatever you > want to get all the features of the app to work correctly. But > please don’t mess up Recommends working correctly for the rest of us. 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. If the lack of kamera made it so that portions of gwenview's user interface were visibly grayed out, or error messages were displayed, then I would see it as a strong dependency since the lack of it results in a substantial degredation of functionality. But when kamera is missing, gwenview still works. Things that try to access the `camera:` KIO slave won't work, but that's the extent of the issues caused. KIO slaves are essentially plugins of sorts, so I see this as an additional "nice-to-have" that isn't a dependency at all. This isn't the only example either - I've had live image builds pull in things that seemed (to me) to be completely "out of left field", like random terminal emulators that I have neither interest in nor willingness to keep in my image builds. (I don't know exactly which package was the culprit there.) The solution you mention is to not automatically install recommended packages. But then you run into "fun" edge cases like system boot failures[1], sudo or user-setup not being installed[2], and things like that. When a packager needs to say "technically package A can function without package B, but only if the user knows exactly what they're doing", Recommends is the only way to express that, and if Recommends is also being used to ship unnecessary terminal emulators, plugins for little-used image viewer functionality, and the like, there's no good solution except for manual fiddling. This is causing real problems in at least one downstream derivative of Debian (Kicksecure, which I am working with), which is why I'm hoping to find a good solution that I can start implementing and sending patches for. This isn't to disagree with you at all - I agree that gwenview shipping kamera as a Recommends is a good thing. Like you say, "I shouldn't have to manually install anything else for [the buttons in the GUI] to work". That's a perfectly logical thing to use a field called Recommends for. But if it's going to be used for that, it would be very beneficial to identify packages that are recommended and important vs. packages that are recommended but not that important. That's what I was thinking Weak-Depends, or a solution similar to it, could do. In the absence of that, demoting kamera to a Suggests would seem more policy-compliant in my opinion, but then again that's just my opinion. (Side note, I wonder if there's a way to implement Weak-Depends that *doesn't* require modifying all of the tons of packages Johannes mentioned. Maybe some way of annotating packages in Recommends as "important" would permit a distinction to be made here in such a way that most tools wouldn't need changes? Those that were updated would be able to understand the distinction, those that weren't would continue to treat Recommends the same way they do today. No idea if that's feasible, just something that went through my head.) [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078792 If systemd-cryptsetup is missing on an encrypted system and one installs dracut with --no-install-recommends, the system will be rendered unbootable. [2]: https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-package-installation.en.html Section 8.4.3
pgpyd4I9j4qPq.pgp
Description: OpenPGP digital signature
