[Pkg-rust-maintainers] Bug#1116210: Bug#1116210: rust-bzip2: please upgrade to v0.6
Jonas Smedegaard
dr at jones.dk
Tue Jan 27 19:13:23 GMT 2026
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.
Thanks,
- 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
More information about the Pkg-rust-maintainers
mailing list