Source: clevis Version: 16-2 Severity: important Tags: bookworm sid User: reproducible-bui...@lists.alioth.debian.org Usertags: usrmerge X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
If clevis is built on a merged-/usr system (as created by new installations of Debian >= 10, debootstrap --merged-usr, or installing the usrmerge package into an existing installation), the path to systemd-reply-password is recorded in the binary package as /usr/lib/systemd-reply-password, rather than the canonical /lib/systemd-reply-password. This can be seen on the reproducible-builds.org infra: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/clevis.html If you have sbuild available, an easy way to reproduce this is to build twice, once with --add-depends=usrmerge and once without. I suspect the same thing would happen if clevis was built on a system where /lib and /usr/lib had instead been unified via a symlink farm. The problematic situation is if the package is *built* on a unified-/usr system, but *used* on a non-unified-/usr system. In this situation, /usr/lib/systemd-reply-password exists on the build system but not on the system where clevis will be used, resulting in the features that use this executable not working correctly. Technical Committee resolution #978636 mandates heading towards a transition to merged-/usr, and this will become a non-issue at the end of that transition; but variation between merged-/usr and non-merged-/usr builds is a problem while that transition is taking place, because it can lead to partial upgrades behaving incorrectly. It is likely that this class of bugs will become release-critical later in the bookworm development cycle. I see that debian/patches/debian/2021-02-10.build-on-non-usrmerge.patch tries to resolve this, but it doesn't seem to be having the desired effect, because /usr is checked before /lib. Since you're applying a Debian-specific patch for this *anyway*, I think the easiest solution is likely to be to change this patch so that the patched result just hard-codes the canonical path: sd_reply_pass = find_program( join_paths('/', 'lib', 'systemd', 'systemd-reply-password'), required: false ) Some developers advocate unifying /lib with /usr/lib via a symlink farm in /lib instead of merged-/usr, but that strategy would have a similar practical effect on this particular package, and the same solution would be required. A side benefit of fixing this is that this change seems likely to be sufficient to make the package reproducible (as recommended by Policy ยง4.15). smcv
