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

[Fabian Grünbichler]

On Tue, Jan 27, 2026, at 8:13 PM, Jonas Smedegaard wrote:
> Quoting Fabian Grünbichler (2026-01-27 19:38:32)
>> On Mon, Jan 26, 2026, at 9:07 PM, Jonas Smedegaard wrote:
>> > Quoting Fabian Grünbichler (2026-01-26 19:42:12)
>> >> On Mon, Jan 26, 2026, at 8:17 AM, 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).
>> >> >
>> >> > That pattern has two weaknesses: It is escapable and it is vague.
>> >> >
>> >> > 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.
>> >> 
>> >> it does. there is only one source package providing the unversioned
>> >> package librust-sqlite-dev (and the corresponding +feature variants),
>> >> rust-sqlite. if that package's version is within the version range, it can
>> >> satisfy both dependencies. if it is not, it can only satisfy one of them. two
>> >> versions of the same package are not co-installable.
>> >
>> > That sounds like a Rust team practice, not a dpkg issue in Debian in
>> > general, which I was reflecting on above.  No problem, I don't mind us
>> > switching to talking about the Rust team conventions, more narrowly.
>> >
>> > Ok, so Rust-team crate packages provide unversioned virtual packages
>> > only for unversioned source packages. Which means that the example
>> > above would ignore a newly introduced version-branch e.g. of
>> > rust-rusqlite-0.29 (same way as e.g. rust-darling-0.14 is done).
>> 
>> Yes, my response was of course fully in the context of Debian Rust (team)
>> packages.
> [...]
>> A version range like rusqlite = ">= 0.29, < 0.39" would thus cross semver
>> boundaries (by virtue of being at 0.Y, where every bump of Y is semver
>> breaking) can only be encoded as
>> 
>> librust-rusqlite+default-dev (<< 0.38.0-~~), librust-rusqlite+default-dev (>= 0.29-~~)
>
> As I understand it, "in the context of Debian Rust (team) packages" and
> "can only be encoded as..." is key to ensuring no dependency "leakage".
>
> Others in Debian may find it interesting that a) Rust crates in Debian
> provide a wealth of virtual packages, but b) taking inspiration from
> cross-boundary declarations in such packages is risky: The pattern of
> using virtual dependencies to cover cross-boundary is not intended to
> cover any crate within a version range available in Debian, but only
> **same-source** crates. In other words, major-versioned virtual
> dependencies are unsafe to use for cross-boundary declarations, and
> consequently that it is unsafe to rely on version-branched source
> packages for cross-boundary dependencies.

Yes, the whole scheme only works because of the restrictions placed
on the source packages providing those packages. A version range is not
generally safe to encode using separate encodings of the lower and
upper bounds, for all the reasons you mentioned earlier in this thread!

Fabian