On Wed, 6 Nov 2024 22:55:43 +0000 Colin Watson <cjwat...@debian.org> wrote:
> 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". That's a good point, and with a solution that focused on what dependencies are for, one could prevent severe issues by marking a dependency as "basic", i.e. without this, basic functionality breaks or is very likely to break. That could be used for things like dracut's dependency on systemd-cryptsetup or live-config's dependencies on sudo and user-setup. Then the user could choose the extra functionality they wanted on a package-by-package basis. There are two kinds of categorization here that should be taken into account - there's the way a package perceives its dependencies, and the way a package perceives itself. For instance, diffoscope may perceive mono-runtime primarily as a tool for disassembling .NET applications into CIL bytecode, while other packages may perceive it primarily as a runtime environment. The way in which a package perceives itself is already handled in Debian (to some degree at least) by the sections mechanism and the priority field, while it sounds like you're talking specifically about how packages perceive other packages, for instance diffoscope could declare its dependency on mono-runtime as being in a group of recommends called "code-disassemblers" or whatever. Is that right? > 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. Agreed. Still though, if a good theoretical solution is found here, I'm willing to at least try implementing it even if it does end up being a lot of work to bring it to fruition. Aaron
pgpLW15c_P7dt.pgp
Description: OpenPGP digital signature
