Source: libapp-options-perl Version: 1.12-2 Severity: important User: m...@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