Source: sympow Version: 2.023.3-1 Severity: important User: m...@linux.it Usertags: usrmerge X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Steps to reproduce: * Have two chroots, containers or complete systems, one with merged /usr and one not * Build sympow on the system with merged /usr * Install and use sympow on the system without merged /usr Expected result: * The package is functionally equivalent to the package you'd get if it had been built on a system without merged /usr * The absolute paths of standard tools in /bin or /sbin do not appear in the package's content as paths in /usr/bin or /usr/sbin * Everything works as intended Actual result: * /usr/bin/sympow contains what appear to be string constants for /usr/bin/sed and /usr/bin/rm (there might be others) * If that binary invokes those commands (I assume it does, but I haven't actually checked) then it will not work on non-merged-/usr systems, where /bin/sed and /bin/rm exist, but /usr/bin/sed and /usr/bin/rm do not A merged-/usr system can be obtained by installing with debootstrap >= 1.0.102 or debootstrap --merged-usr, or by installing the usrmerge package. A non-merged-/usr system can be obtained by installing with debootstrap --no-merged-usr (or upgrading from an older release) and not installing usrmerge. Recent tests on tests.reproducible-builds.org use unmerged /usr for the first build and merged /usr for the second, as a way to detect some issues in this class. smcv