Bug#914088: sympow: wrong sed, rm paths when built on a merged-/usr system and run on a non-merged-/usr system

[Simon McVittie]

Source: sympow
Version: 2.023.3-1
Severity: important
User: md at linux.it
Usertags: usrmerge
X-Debbugs-Cc: reproducible-bugs at 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