Please upgrade crate bzxip2 to v0.6.
-----BEGIN PGP SIGNATURE-----

wsG7BAEBCgBvBYJo09AwCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmcUVSJ6hKPWZvYEz59ieyMsL4OqRZQBth1lcHbZv6eC
axYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAAATpQ//aW7GsL1dAtW3IrSeN/4rjpmy
cobQ+0+IoxOFZwplP/AJvXy+Q/Fjxr4VezG3zInO0/WQle3ER5HwmGIPL1VDt3hR
uCeabvNev+Eii41XgHnP+6eCjRUXn9A825zsruZJoVGxTO1kYDIanfy/ivanv5vb
hlK59qsPF2yovz+IRw/7xKnMqLJ4CGqN2czECpPonSMe4TdNSCN2Ad3YpcQXYVjF
7UeNg6oMWfWkjWVdxMr7MwGWo5wJNoaKsfkbVJZqgmOVTmivNmAtk56f//5I2CWW
oPJ5TDsnC2Qui3lXOG82BsyFIn/XGBR8qwh8vTFdn+KsXmiDkp+9QX34jesKOTpB
c6JjpsM9NREqUhN76rT9yvpv4md3pJRNbHvMO2PnCWMALR9curnrIVXtmZzevT9N
rMEMTSB2O/XrddYakFRSbOz3dJW9HO76tm59xe6zHjdUAjC1yoma0lBLBYbNNL1N
xrp9yiNLkvUeFFOhmjeF5lgbqtwBqtdv7n+rR5CaHx2Zehz/3g88/w4bX4oJPYLK
1tD/5BwlB+b64x06kCIpzBdTrhxaF7NapW59SWJV2c7N/ZEXbEjpRclt63dyhHvG
xovNNcjps5CnC1wsyTwEnatngmRLO/wVg4OonwOTOcsFaceoCiIDA+RW222Hql1x
w8M+QAprdJ+l93JNQB4=
=itPf
-----END PGP SIGNATURE-----

Hi Jonas--

I've just upgraded rust-bzip2 to 0.6.1.  Please update the patch in
rust-rustls-webpki accordingly so that they can migrate together :)

BTW, i note that debian/patches/2002_bzip2.patch adjusted the crate
dependencies this way:

Hi Jonas--

I've just upgraded rust-bzip2 to 0.6.1.  Please update the patch in
rust-rustls-webpki accordingly so that they can migrate together :)

BTW, i note that debian/patches/2002_bzip2.patch adjusted the crate
dependencies this way:

Hi Daniel,

Quoting Daniel Kahn Gillmor (2026-01-25 03:42:26)

Thanks. Will do now.
equivalent to "<= 0.6.*" (not "<= 0.6.0"). 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.

I find <= easier to read than << (even if only for the upstream part -
dpkg lacks that syntax).

Please do insist, if you still think I am wrong here. Of course :-)

 - Jonas

Hi Daniel,

Quoting Daniel Kahn Gillmor (2026-01-25 03:42:26)

Thanks. Will do now.
equivalent to "<= 0.6.*" (not "<= 0.6.0"). 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.

I find <= easier to read than << (even if only for the upstream part -
dpkg lacks that syntax).

Please do insist, if you still think I am wrong here. Of course :-)

 - Jonas

We believe that the bug you reported is fixed in the latest version of
rust-rustls-webpki, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1116210@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jonas Smedegaard <dr@jones.dk> (supplier of updated rust-rustls-webpki package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 25 Jan 2026 09:47:26 +0100
Source: rust-rustls-webpki
Architecture: source
Version: 0.103.9+ds-2
Distribution: unstable
Urgency: medium
Maintainer: Jonas Smedegaard <dr@jones.dk>
Changed-By: Jonas Smedegaard <dr@jones.dk>
Closes: 1116210
Changes:
 rust-rustls-webpki (0.103.9+ds-2) unstable; urgency=medium
 .
   * relax build- and autopkgtest-dependencies for crate bzip2;
     closes: bug#1116210, thanks to Daniel Kahn Gillmor
   * update copyright info:
     + really avoid any .git* files when repackaging upstream source
   * update git-buildpackage config:
     + stop superfluously filter out .git* files
Checksums-Sha1:
 13d48e30d0f46f964dff6cb650b2d51afbdc453e 2747 rust-rustls-webpki_0.103.9+ds-2.dsc
 e4e1c929d5eee079c146c3414d8836bb9032370e 9040 rust-rustls-webpki_0.103.9+ds-2.debian.tar.xz
 c964d48371e1e929a0e8e73dc33afc63f30a7eae 18003 rust-rustls-webpki_0.103.9+ds-2_amd64.buildinfo
Checksums-Sha256:
 74e233286f45a84899ff3c7e1d82e54870a2de79f471d1089f29a5a4304df138 2747 rust-rustls-webpki_0.103.9+ds-2.dsc
 bc714bc69edeb7036d185642940c7bb8ae1a5447734dd11ee4411432007aa5c8 9040 rust-rustls-webpki_0.103.9+ds-2.debian.tar.xz
 9e48756e7d4c171e08e562029acb043d23a6ad8a8d287b6ed4945d282385f614 18003 rust-rustls-webpki_0.103.9+ds-2_amd64.buildinfo
Files:
 9494ac632725112666df254d2791d2a7 2747 rust optional rust-rustls-webpki_0.103.9+ds-2.dsc
 ba53587167ec804c40108236f59bf464 9040 rust optional rust-rustls-webpki_0.103.9+ds-2.debian.tar.xz
 f78d9f1457904d61843855eb6958b90d 18003 rust optional rust-rustls-webpki_0.103.9+ds-2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAml12OEMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhhP4P/AyYC+iiDi50TtFo2AFvZqKc7vO9SBt5gJ8uv6to
/FFc+tI4OTOwbvbxj/cWjjF4L4uPez2o1ghnuOyLE570eay28/RAT7lXIXOxrOE0
UXqXQ6JJzzljBHYttEODd8LmPxFnPZgVZzhg0RypnkyZC+tyIXWpnm0jeYYtO5yq
aSJV4T2bwL31/bX5nKzNPw8jQHKH6V+LraMzdvk1fYAf+DtzUC843hyGuD1ZiAkC
haNw0LmD7WBeb0VDgxdifK+GbCaYF/v7pDX36g55lwwInGaNfDCR8Pg2/KdObLVb
UC1gsEh/bjZuLC7ewGPO9mY5TnwIdUMuouvCC6oNeUZ86hRXwe9Al1b9DfNugSjT
vX4x/JCCQvIbaqKxQI5C9LHgtk/gLQc0BnKr6RKuPrjV7av2GWPg1SxrkllSXUcz
5m+7UEAnqgWt86gG8Al3OCgr5yv+KhfgMjh+YYgXO+AKWHBlir+DwB1VdzK73456
a0/JcnUf55FCxTkw2LLPM875gfQG1qV1aaTrXZKFR/abGyRhs8VayYsSolDJkGot
xqpTzMcqZ3vtuRSPvpMVYArRf8ai2pCOchIvFMMR5AkUUUc60iHsML/kH5tGapT2
WgQ/7e3hH3rROaHaBSsch67lAzyPBMl4x6jJ8v7xgRe6xwBoY+dAltCdiu8hNX5x
75ZJ
=HTvr
-----END PGP SIGNATURE-----

Hi Jonas--

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 you have evidence that this works, that's good enough for me.

Looking in git, i see that what you changed was just the explicit
build-deps (and test deps), without modifying the Cargo.toml patch.  And
i see that it builds and tests safely now ☺

Thanks for pointing me in the right direction!

Happy new year, Jonas!

Quoting Daniel Kahn Gillmor (2026-01-26 05:23:44)
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 to you as well, my friend!

 - Jonas

Hi Jonas--

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

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

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.

Quoting Daniel Kahn Gillmor (2026-01-26 18:28:46)

Heh, I forgot to consider that obvious case of upstream providing the
cross-boundary declaration, and Debian merely echoing that. :-)

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

Yes, understood.

I would prefer the nuanced provisions was only declared for complex
packages, not by default for thousands of packages without a need.

 - Jonas

CC-ing the Rust team discussion list

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.

if the version range does not cross semver boundaries, then the range is not
encoded using the unversioned package, but using the "semver-dominant"
component. e.g., a range like >= 2.1, < 2.4 would be encoded as
librust-foobar-2-dev (>= 2.1-~~), librust-foobar-2-dev (<< 2.4), which might be
satisfied by librust-foobar-2-dev built from rust-foobar-2 or by
librust-foobar-dev built from rust-foobar. in practice this is not an issue
either, since introducing rust-foobar-2 coincides with upgrading rust-foobar to
3 (or higher).

this encoding was carefully chosen because the old way we encoded such version
ranges (using alternate build-/dependencies) was broken (indeterministic) and
not policy compliant. the rust team book still contains the old encoding, I
will update this ASAP.

yes. but such ranges are only like that (crossing semver boundaries) when
upstream does so, or patching downstream (which is a statement by the
maintainer that those versions should not have - mattering - breaking changes).

we (as in, the Rust team) have discussed dropping both the full 3-component
version provides/depends (those are rarely needed in the first place[0,1])
and/or reducing the amount of feature related provides/depends. it requires
careful thought to not miss edge cases.

in general, reducing dependencies like that should work. of course, it doesn't
account for valid package split along feature lines, or the fact that the
unversioned package is only provided by the non-semver-suffixed source package.
so if you reduce dependencies in that fashion, it will likely work - but you
might be asked to adapt if a package is split or semver-suffixed later on, as
your package might FTFBS without those adaptations.

Fabian

0: https://salsa.debian.org/rust-team/debcargo/-/merge_requests/66
1: https://salsa.debian.org/rust-team/debcargo/-/issues/70

Hi Fabian,

Quoting Fabian Grünbichler (2026-01-26 19:42:12)

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

If we wanted the cross-boundary dependency to take alternative packages
into account, then dependencies would need to be adjusted to instead be
zero-bound (looking at how rust-darling-0.14 and rust-darling both
provide zero-versioned virtual packages), but that would introduce the
issue of "leaky" dependencies.

Makes sense (except for the "either", see above).

I am not familiar with that older style. Thanks for checking and fixing
documentation related to that.
"lesser-than-any-debian-revision" rune, but would simplify to this:

  librust-rusqlite-dev (<< 0.38)

Thanks for considering. Yes, I am aware it is not simple to do the
change.

Makes sense.

Thanks for your comments,

 - Jonas

Yes, my response was of course fully in the context of Debian Rust (team)
packages.

For the avoidance of doubt, I'll spell out the policy ;)

rust-foobar will build librust-foobar-dev which will provide:
- librust-foobar-X-dev
- librust-foobar-X.Y-dev
- librust-foobar-X.Y.Z-dev
as well as (for every feature, `foobaz` being an example here):
- librust-foobar+foobaz-dev
- librust-foobar-X+foobaz-dev
- librust-foobar-X.Y+foobaz-dev
- librust-foobar-X.Y.Z+foobaz-dev

For some packages there might exist a separate binary package
librust-foobar+something-dev, which again provides all those versioned variants
for +something, as well as an unversionend and all the versioned variants for
other features that are grouped together with `something`.

Semver-suffixed packages like rust-foobar-0.Y or rust-foobar-X (where X != 0)
will build the corresponding librust-foobar-0.Y-dev / librust-foobar-X.dev,
which will provide
- librust-foobar-X-dev (if not already the binary package name)
- librust-foobar-X.Y-dev (if not already the binary package name)
- librust-foobar-X.Y.Z-dev
as well as (for every feature, `foobaz` being an example here):
- librust-foobar-X+foobaz-dev
- librust-foobar-X.Y+foobaz-dev
- librust-foobar-X.Y.Z+foobaz-dev

The same "there might be other +something binary packages" applies here as
well.

So in the case of rusqlite, at the moment, since it is still at version 0.x, we
will have rust-sqlite (the latest packaged version) and possibly
rust-sqlite-0.Y for various values of Y.

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

which can never be satisfied by packages built from rust-sqlite-0.Y, but only
by those built by rust-sqlite itself. by virtue of only a single version of
that package being installable, that single version must either satisfy both
version constraints, or none or only one, in which case the
(build-)dependencies would not be satisfiable.

The version range encoding is special for that reason - we only emit ranges as
dependencies that are satisfiable by:
- only the packages built by rust-foobar (if range crosses semver boundaries)
- the packages built by rust-foobar-X(.Y) and rust-foobar, while both are still
  at the same semver version (during the transition itself, if the range
  doesn't cross semver boundaries)
- the packages built by rust-foobar-X(.Y), if the range doesn't cross semver
  boundaries and the transition is done and rust-foobar has moved on

I hope the more detailed explanation above makes sense :)

the older style was:

foobar = ">= X, < Z" => librust-foobar-X-dev | librust-foobar-Y-dev | .. | librust-foobar-Z-dev

possibly with version constraints at the X and Z packages. this runs afoul of
the "buildds only pick first option in alternate dependencies" principle.

FWIW, I plan to drop those pesky -~~ in debcargo, they make no sense AFAICT:

https://salsa.debian.org/rust-team/debcargo/-/issues/53
https://salsa.debian.org/rust-team/debcargo/-/commit/bdecd4e11c368c5768998aa7c5c401396e827bb3

Quoting Fabian Grünbichler (2026-01-27 19:38:32)
[...]

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

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