On Wed, Nov 06, 2024 at 04:06:59PM -0600, Aaron Rainbolt wrote: > (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.)
In some ways I think what we're missing is really a way to do the equivalent of "extras" in Python packages (https://peps.python.org/pep-0508/#extras): effectively groups of additional dependencies to enable some kind of feature that you can opt into if you need that feature, rather than having to pick from an undifferentiated pile of Recommends, or do things like devscripts does where you explain the Recommends you need for various tools in your package description (and hope that they never change, because people might not know that they need to keep up). I don't think the proposed Weak-Depends particularly helps with that; it adds another fine gradation along the axis of "how important is this dependency", rather than considering the orthogonal axis of "what is this dependency for". In most cases you can get around this sort of thing using some extra metapackages. This is usually workable, but since it involves a trip through NEW people are reluctant to do it too much, and it contributes to Packages bloat. Still, I entirely agree with those who've said that adding new package relationship fields is a _lot_ of work and should have a very high bar, and the same goes for extending the syntax of existing fields. Not to mention that we're kind of running out of convenient ASCII punctuation characters. -- Colin Watson (he/him) [cjwat...@debian.org]
