[Pkg-rust-maintainers] Bug#1149034: Debian NEW review of rust-derivre 0.3.12-3: ACCEPTED

[Fabian Grünbichler]

On Thu, Oct 1, 2026, at 11:57 AM, awm at debian.org wrote:
> The Debian NEW review of rust-derivre 0.3.12-3 has been completed.
>
> Decision: ACCEPTED
> Reviewer: Andrew McMillan

Thanks for the review!

> Review comment:
>
> Hi,
>
> Some packaging-quality issues.  I suspect you already know these though...
>
> Major downgrade of hashbrown (0.17.1 → 0.14.5).
>
> Cargo.toml.orig:20 requires 0.17.1, but 
> debian/patches/relax-version.patch rewrites it to 0.14.5 (two major 
> versions older) purely because Debian only has 0.14 (control:18,37). 
> The crate uses hashbrown::hash_table::Entry/HashTable 
> (src/hashcons.rs:1,4), which still exist in 0.14 so it compiles, but 
> this silently changes the hash-table implementation upstream pinned — 
> worth flagging for review rather than accepting blindly.

This is expected - unfortunately the upstream Rust ecosystem tends to
bump in a semver-incompatible fashion rather often (much more often
than regular C libraries would bump their soname), often for minor
issues not relevant for most reverse dependencies. Coupled with a
tendency to blindly bump dependency versions to the latest, without
actually using any of the newly introduced features/interfaces, we
end up with a wide range of versions of any particular crate in the
wild, where versions can be nominally incompatible, but mostly
compatible in practice. Of course *real breaking changes* exist as
well. If we would not have a lot of patches down- or upgrading
version constraints in Cargo.toml, we'd run afoul of the goal of not
having N versions of any particular upstream project in the archive,
if we can avoid it. We try to keep the number of "semver-suffixed"
crate packages (rust-foo-N or rust-foo-0.N) to what is actually
needed.

Such patches make up the vast majority of patching that happens in
rust-* packages.. Dropping them would mean introducing a lot more
rust-foo-N packages, which would make our lives and that of other
teams (including the DFSG team ;)) harder!

> Test-only dev-dependencies missing from Build-Depends-Arch.
>
> The crate's test targets (tests/basic.rs, fowler.rs, etc.) depend on 
> bstr, serde, toml (Cargo.toml:86-99), but none of these appear in 
> control Build-Depends. They're only listed in debian/tests/control for 
> autopkgtest. Since debian/rules is a plain dh $@ --buildsystem cargo 
> with no nocheck, the build-time test run cannot build these targets — a 
> likely FTBFS unless tests are intentionally skipped. (Worth verifying 
> against CI.)

This is also expected. dev-dependencies often introduce cyclic
dependencies which would make upgrading and testing migration harder
if included as regular build dependencies.

debcargo generated source packages will do the following:
- if there are no dev-dependencies in Cargo.toml, the test suite
is run as part of the build and as autopkgtests
- if there are dev-dependencies in Cargo.toml, at build time only a
build test is done, the full test suite is postponed to autopkgtests

Hope this does sound reasonable :)
Fabian