On Thu, Oct 1, 2026, at 11:57 AM, [email protected] 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
