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

[Andrew McMillan]

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

-- 
----------------------------------------------------------------------
Porirua, New Zealand                                 +64 (27) 288 6741
                    https://andrew.mcmillan.net.nz

     Do nothing unless you must, and when you must act: hesitate.
----------------------------------------------------------------------