Thanks for the response. yes - as I stated in my earlier e-mail - I expected that these things were known and understood.
Cheers, Andrew. On Thu, 2026-10-01 at 19:39 +0200, Fabian Grünbichler wrote: > 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 -- ---------------------------------------------------------------------- Porirua, New Zealand +64 (27) 288 6741 https://andrew.mcmillan.net.nz Do nothing unless you must, and when you must act: hesitate. ----------------------------------------------------------------------
