Bug#993275: ng: stores wrong paths to cp and ls if built on merged-/usr system

[Simon McVittie]

Source: ng
Version: 1.5~beta1-9
Severity: important
Tags: patch bookworm sid
User: reproducible-builds at lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-bugs at lists.alioth.debian.org

If gnunet is built on a merged-/usr system (as created by new
installations of Debian >= 10, debootstrap --merged-usr, or installing
the usrmerge package into an existing installation), the paths to cp and
ls are recorded in the binary package as being in /usr/bin, rather than the
canonical /bin.

This can be seen on the reproducible-builds.org infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ng.html

If you have sbuild available, an easy way to reproduce this is to build
twice, once with --add-depends=usrmerge and once without.

I suspect the same thing would happen if ng was built on a system where
/bin and /usr/bin had instead been unified via a symlink farm.

The problematic situation is if the package is *built* on a unified-/usr
system, but *used* on a non-unified-/usr system. In this situation,
/usr/bin/cp, etc. exist on the build system but not on the system where
the package will be used, resulting in the features that use this
executable not working correctly.

Technical Committee resolution #978636 mandates heading towards a
transition to merged-/usr, and this will become a non-issue at the end of
that transition; but variation between merged-/usr and non-merged-/usr
builds is a problem while that transition is taking place, because it
can lead to partial upgrades behaving incorrectly. It is likely that
this class of bugs will become release-critical later in the bookworm
development cycle.

The attached patch resolves this: with it applied, the package builds
identically with and without --add-depends=usrmerge.

Some developers advocate unifying /bin with /usr/bin via a symlink farm
in /bin instead of merged-/usr, but that strategy would have a similar
practical effect on this particular package, and the same solution would
be required.

A side benefit of fixing this is that this change seems likely to be
sufficient to make the package reproducible (as recommended by Policy
§4.15).

    smcv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-d-rules-Specify-canonical-paths-of-cp-ls-mv-rmdir.patch
Type: text/x-diff
Size: 1743 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-bugs/attachments/20210829/9c88d880/attachment.patch>