XPost: linux.debian.ports.hurd, linux.debian.maint.glibc

Source: glibc
Version: 2.37-15
Severity: normal
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-Cc: debian-hurd@lists.debian.org, debian-cross@lists.debian.org

Hi,

one of the reasons for DPKG_ROOT support in packages close to the essential and build-essential set is to build chroots for architectures that do not have qemu-user support. Building chroots for hurd from linux is one such scenario where qemu-user emulation will never allow running hurd binaries from the chroot on the linux system creating that chroot and thus the only way to create it (short of running the whole thing inside a full virtual machine) is to use chrootless mode.

In our last round of DPKG_ROOT related patches we built chroots for other linux architectures on linux. Now we try building chroots for foreign kernels. In this case: hurd on linux. In the process we discovered another problem class: maintainer scripts running uname. This is a problem because "uname -s" will print "Linux" and thus the linux-specific parts of the maintainer script get executed but we want to build a hurd chroot and need the hurd-specific bits instead.

In case of libc.preinst, its use of "uname -s" and "uname -r" can be avoided by adding another condition on $DPKG_ROOT being empty, i.e to only check the kernel version for normal installations but not when glibc is installed with dpkg --force-script-chrootless as in that case, there exists no way for the script to know what kernel version will be running on the final system where the chroot will be deployed. So if "$DPKG_ROOT" is not empty, the kernel version checks just get skipped.

I submitted a patch as a merge request here:

https://salsa.debian.org/glibc-team/glibc/-/merge_requests/20

Please consider applying it to close this bug.

What do you think?

Thanks!

cheers, josch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)