Quoting Daniel Kahn Gillmor (2026-01-26 18:28:46) > On Mon 2026-01-26 08:17:30 +0100, Jonas Smedegaard wrote: > > I have noticed a common pattern in the Rust team of including features > > when declaring version constraints, like this: > > > > librust-rusqlite+blob-dev (<< 0.38-~~) > > librust-rusqlite+blob-dev (>= 0.29-~~) > > > > (the example is from librust-sequoia-cert-store-dev that you might be > > directly familiar with). > > This example is derived from the notation provided by the sequoia-cert-store > upstream crate, which has the following stanza in their editor's copy of > Cargo.toml: > > [dependencies.rusqlite] > version = ">=0.29, <0.38" > features = ["collation", "blob", "trace"]
Heh, I forgot to consider that obvious case of upstream providing the cross-boundary declaration, and Debian merely echoing that. :-) > > It is escapable because it permits a too old *and* and too new version, > > e.g. in above example it does not rule out Debian packages versioned > > 0.28-1 and 0.39-1. > > i think you're saying that the debian constraints could somehow be > satisfied by two separate packages, one of which exceeds the lower > bound, and the other of which exceeds the upper bound, as long as they > both "Provide: librust-rusqlite+blob-dev". Am i interpreting this > correctly? (if so, i don't think i know how to solve it, it's an > interesting puzzle) Yes, that is what I am saying. Thanks for the more clear rephrasing. If I understand correctly, it is not solvable using Debian versioning syntax - and that was the reason that the Rust team insisted on introducing the +feature and -MAJOR and -MAJOR-MINOR provisioning, despite pushback from ftpmasters arguing that it would bloat metadata for everyone: They (i.e. mainly Ximin Luo and Josh Triplett) expected a need for fending against at least some such dependency "leakage". > > It is vague because it crosses semver stability boundary, so "blob" is > > not guaranteed to mean the same thing across those 10 subscopes. That > > also goes for the "default" feature, that may change which other > > features it includes. > > What upstream is expressing here is exactly this: "we understand the API > guarantees offered by released versions of the rusqlite crate's blob > feature that meet these constraint bounds are stable enough to be used > by this version of sequoia-cert-store." > > That is, while the dependency's versions may be semver-incompatible > (e.g. because features were removed or changed substantively) the > *subset* of the rsqlite+blob API that is actually used by > sequoia-cert-store is stable. Yes, understood. > > I would, for dependencies that cross semver stability boundaries, stop > > care about feature and stop care about the least concerning of either > > upper or lower bounds, e.g. for the above example (where we factually > > know that lower bounds is not an issue) I would instead declare this: > > > > librust-rusqlite-dev (<< 0.38-~~) > > > > That is half the amount of nodes to compute in the dependency graph, > > and a reduction in potentials for complexity due to reduces possibility > > types of edges. And likely more important, it reduces the size of the > > packaging metadata. > > This is an interesting proposal, but i'm not sure how i'd weight the > difference, given that the packaging metadata should be compressed, and > the choice of feature is actually kind of an important statement in the > dependency graph. Some librust-*-dev crates ship differently with > different features (see the long collapse_features discussions in the > rust-team), where separate features pull in additional sub-dependencies. > > I wouldn't want to lose that nuanced capability without having something > clear to replace it. I would prefer the nuanced provisions was only declared for complex packages, not by default for thousands of packages without a need. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
