Source: ksh93u+m Version: 1.0.0~beta.1-3 Severity: important Tags: patch bookworm sid User: [email protected] Usertags: usrmerge X-Debbugs-Cc: [email protected]
If ksh93u+m 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 tput is recorded in the binary package as /bin/tput, rather than the canonical /usr/bin/tput. This can be seen on the reproducible-builds.org infra: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ksh93u+m.html If you have sbuild available, an easy way to reproduce this is to build twice, once with --add-depends=usrmerge and once without. 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, /bin/tput exists on the build system but not on the system where the package will be used, resulting in the features that use this executable not working correctly. Similarly, if there is a /usr/local/bin/tput visible at build-time, then that path would likely end up hard-coded into the binary, causing the relevant feature to fail on all systems that do not have /usr/local/bin/tput. Technical Committee resolution #978636 mandates heading towards a transition to merged-/usr, and 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. The attached patch resolves this: with it applied, the package builds identically with and without --add-depends=usrmerge. Unfortunately I was not able to find a way to do this via build-time configuration, which would have been preferable to patching. Some developers advocate unifying /bin with /usr/bin via a symlink farm in /bin 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 might be sufficient to make the package reproducible in general (as recommended by Policy ยง4.15). smcv
From: Simon McVittie <[email protected]> Date: Mon, 6 Dec 2021 11:23:37 +0000 Subject: Hard-code tput to be found at /usr/bin/tput Otherwise, if ksh is built on a merged-/usr system, we might find it at /bin/tput, which is equivalent to /usr/bin/tput on a merged-/usr system, but does not exist if the resulting package is used on a traditional split-/usr system. Similarly, if /usr/local/bin/tput exists on the build system, it will probably not exist on the system where the resulting package is to be used. In Autotools, this would usually be done by setting TPUT=/usr/bin/tput at configure time, but this package uses its own vaguely similar setup instead of an Autotools configure script and does not appear to offer a corresponding mechanism to override the auto-detected path, so we'll have to hard-code this as a Debian-specific change. Signed-off-by: Simon McVittie <[email protected]> Forwarded: not-needed, Debian-specific --- src/cmd/ksh93/features/cmds | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/cmd/ksh93/features/cmds b/src/cmd/ksh93/features/cmds index 87d211c..171752e 100644 --- a/src/cmd/ksh93/features/cmds +++ b/src/cmd/ksh93/features/cmds @@ -4,7 +4,7 @@ pth ed fail{ echo '#define _pth_ed "ed" /* ed not found on standard PATH */' }end -pth tput +pth tput /usr/bin tput_terminfo note{ does tput support terminfo codes }end run{ TERM=ansi
