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

[Jonas Smedegaard]

Quoting Daniel Kahn Gillmor (2026-01-26 05:23:44)
> Hi Jonas--
> 
> On Sun 2026-01-25 09:42:21 +0100, Jonas Smedegaard wrote:
> > Thanks, but I think you are mistaken: In my experience, "<= 0.6" is
> > equivalent to "<= 0.6.*" (not "<= 0.6.0").
> 
> Interesting, thanks for pushing back and making me reconsider this!
> 
> i read the cargo specification for version requirements:
> 
>   https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#version-requirement-syntax
> 
> and it appears to be ambiguous about what an explicit comparator means
> if the patch level is unspecified.
> 
> > If I was mistaken, then I believe that e.g. oxigraph, which for some
> > time has carried this line:
> >
> > quick-xml = ">= 0.37, <= 0.38
> >
> > would FTBFS with librust-quick-xml-dev 0.38.4-1, and that works fine.
> 
> If you have evidence that this works, that's good enough for me.

Speaking of versioning of Rust crates, I thought of another related one
just after hitting send yesterday:

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

Neither of those issues are likely to matter - escapability because the
Debian archive is unlikely to have enough parallel versions for a crate
to satisfy both lower and upper bounds by wrong versions, and vagueness
because it is unlikely that upstream meant something extraordinarily
different.

But both those antipatterns, even if dismissable, causes bloat in
Debian metadata.

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.

> Happy new year, Jonas!

Happy new year to you as well, my friend!

 - 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/eb437d1f/attachment.sig>