[Pkg-rust-maintainers] Bug#1116210: rust-bzip2: please upgrade to v0.6

[Jonas Smedegaard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20260126/d2f80ec5/attachment-0001.sig>