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

[Daniel Kahn Gillmor]

Hi Jonas--

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"]

> 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)

> 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.

> 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.

      --dkg