Source: ng
Version: 1.5~beta1-9
Severity: important
Tags: patch bookworm sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@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
>From 483dd087b93e02d30a7bf1f022c35d3f88f74d07 Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Sun, 29 Aug 2021 22:15:25 +0100
Subject: [PATCH] d/rules: Specify canonical paths of cp, ls, mv, rmdir
When ng is built on a system where both /usr/bin/cp and /bin/cp
exist (either merged-/usr or via a symlink farm), this results in storing
/usr/bin/cp in the installed programs, which will not work as intended
on systems where only the traditional path /bin/cp exists.
ls is in a similar situation. mv and rmdir are checked by ./configure
but not hard-coded anywhere; give them the same treatment for symmetry.
Signed-off-by: Simon McVittie
---
debian/rules | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/debian/rules b/debian/rules
index 3363b4b..9f0f48b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,13 @@ export CC
DOCDIR = usr/share/doc/ng-common
+configure_environment = \
+ ac_cv_path_cp_cmd=/bin/cp \
+ ac_cv_path_ls_cmd=/bin/ls \
+ ac_cv_path_mv_cmd=/bin/mv \
+ ac_cv_path_rmdir_cmd=/bin/rmdir \
+ $(NULL)
+
configure: configure-stamp
configure-stamp:
dh_testdir
@@ -34,21 +41,21 @@ build-stamp:
# vanilla ng-latin
cp -p debian/config-latin.h config.h
- ./configure
+ $(configure_environment) ./configure
$(MAKE)
mv ng ng-latin
$(MAKE) confclean
# ng-cjk
cp -p debian/config-cjk.h config.h
- ./configure
+ $(configure_environment) ./configure
$(MAKE)
mv ng ng-cjk
$(MAKE) confclean
# ng-cjk-canna
cp -p debian/config-cjk-canna.h config.h
- ./configure --enable-canna
+ $(configure_environment) ./configure --enable-canna
$(MAKE) CANNADEF="-DCANNA" CANNALIB="-lcanna"
cp -p ng ng-cjk-canna
--
2.33.0
