Control: severity -1 serious On Tue, 30 Nov 2021 at 19:18:33 -0800, Vagrant Cascadian wrote: > The paths to various binaries are embedded which differs on a usrmerge > vs. non-usrmerge system. > > > https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/gcc-riscv64-unknown-elf.html > > /usr/lib/gcc/riscv64-unknown-elf/8.3.0/install-tools/fixincl > > /bin/sed > vs. > /usr/bin/sed
This will be a practical problem as soon as Debian starts using merged-/usr on official buildds, and the Debian technical committee resolution https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends treating this class of bug as release-critical for Debian 12, so I'm raising the severity of this bug. The problem scenario is: - build the package on a system where both /bin/sed and /usr/bin/sed exist (merged-/usr) - install and run the package on a system where only /bin/sed exists (non-merged-/usr) - result: the feature that runs sed will not work I don't know the specifics of how the tools that embed these paths work, so it's possible that I am overstating the severity of this bug. If the embedded paths are not used at runtime in practice, then the severity of this bug can be downgraded to non-RC (but it would be better to fix it anyway, because reproducible builds are a useful goal for other reasons). > Patch attached which passes variables to configure to use the > non-usrmerge locations, as usrmerge installations typically have > compatibility symlinks, but not vice-versa. The patch also sets > variables to ensure consistent values for bash, which can be triggered > when /bin/sh points to bash. This looks appropriate. To clarify, Debian installations with merged-/usr are *guaranteed* to have the compatibility symlinks such as /bin -> usr/bin, so it is always appropriate to use the canonical non-merged-/usr paths such as /bin/sed. Thanks, smcv
