Bug#913637: /usr/bin/prefix: won't work if built on a merged-/usr system and used on an unmerged-/usr system

[Simon McVittie]

Source: libapp-options-perl
Version: 1.12-2
Severity: important
User: md at linux.it
Usertags: usrmerge

libapp-options-perl appears to have a build bug that can be reproduced
as follows (I haven't actually tested this myself, I'm basing this on
reproducible-builds logs):

* Have two systems/chroots/containers, one with merged /usr (/bin is a
  symlink to /usr/bin) and one without
* Build libapp-options-perl on the first system
* Install it on the second system and use /usr/bin/prefix

Expected result:

* prefix is a #!/bin/bash script and works correctly

Actual result:

* prefix is a #!/usr/bin/bash script and won't start on non-merged-/usr
  systems

Broader context: I recently added a new point of variation (#901473)
to Debian's reproducible builds infrastructure: the first build is done
in a traditional Debian system with separate /bin and /usr/bin, while
the second is done with merged /usr (/bin is a symbolic link to /usr/bin).
This was done to detect bugs similar to #913226 in quilt.

libapp-options-perl appears to have the class
of bug that this was meant to detect.  If you look at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libapp-options-perl.html
you'll see that in the first build, /usr/bin/prefix has

#!/bin/bash

whereas in the second, /usr/bin/prefix has

#!/usr/bin/bash

an interpreter that doesn't exist on non-merged-/usr systems.

I don't know what part of the build rewrites that first line or how to
fix it. Please reassign this bug if it's really a bug in generic Perl
build infrastructure.

Mitigation: if you do source-only uploads, the older debootstrap currently
in use on buildds will create non-merged-/usr schroot tarballs, so users
will not currently experience this bug. (However, if stretch-backports'
debootstrap is brought up to date with buster and deployed to buildds
without first applying #913228, that mitigation will go away.)

    smcv