Package: libzstd
Version: 1.5.7+dfsg-3
Severity: normal
Tags: reproducibility upstream
The `zstd` binary `.deb` produced by the libzstd source package is not
byte-identical when built with `DEB_BUILD_OPTIONS=parallel=1` versus
`parallel=2` (or higher).
Reproduction:
1. Get source: `apt-get source libzstd`
2. Build twice with different parallel values, in fresh trees each time:
DEB_BUILD_OPTIONS="parallel=1 nocheck" dpkg-buildpackage -b --no-sign
DEB_BUILD_OPTIONS="parallel=2 nocheck" dpkg-buildpackage -b --no-sign
3. Compare the resulting `zstd_1.5.7+dfsg-3_<arch>.deb` files (e.g. with
sha256sum or diffoscope).
Expected: identical bytes.
Observed: 8-byte size difference. The metadata difference visible in
dpkg-scanpackages output: at parallel >= 2 the package declares `Commands:
zstd` (auto-populated substvar listing CLI commands provided); at parallel = 1
the field is absent from the produced .deb's control. The other 4 binaries this
source produces (libzstd1, libzstd1t64, libzstd-dev, libzstd-tools) are
byte-identical across the same matrix; only the `zstd` binary drifts.
Suspected cause: an ordering issue in debian/rules between the step that
populates the `Commands` substvar (`dh_installcommands` or equivalent — the
consumer of `debian/zstd.commands`) and the step that assembles the .deb's
control via dpkg-gencontrol. At parallel = 1 these run in the wrong order; at
parallel >= 2 the parallel scheduler happens to order them correctly.
Make-level dependencies between them would make the result independent of the
scheduler.
Impact: breaks Debian Reproducible Builds for `zstd` specifically. Distribution
rebuilders and downstream users can't get bit-identical `zstd` .debs without
standardizing on a specific parallel=N value.
Tagging upstream because the fix likely lives in libzstd's debian/rules.
