On Thu 2020-10-15 16:44:00 -0400, Daniel Kahn Gillmor wrote: > Are there design constraints or goals that this approach doesn't solve?
Hm, Guillem pointed me toward https://bugs.debian.org/901827 which identifies non-contiguous ranges of dependencies due to "transitive dependencies on multiple versions of the same package" I don't really understand the distinction (still!), but it seems to me like this is probably not the general case. Rather, it's a corner case that seems to be driving all the rest of the complexity here. It's also pretty troubling that mdbook (the example in #901827) includes three different versions of slab and two different versions of mio. Is this really a desirable outcome? I'm looking for ways to reduce the overall complexity of the system. Seems to me like right now we have a choice between (a) making it impossible to package crates with snarled dependency trees like mdbook, or (b) making it hard (but not impossible) to maintain pretty much all other crates that have more straightforward dependency trees, or (c) implementing ranged dependencies in dpkg. At the moment, we seem to be going with (b), which i'm not very fond of because i tend to work on those particular kinds of packages. --dkg
signature.asc
Description: PGP signature
