Hi Simon, On Fri, Jan 03, 2025 at 10:43:21AM +0000, Simon McVittie wrote: > (I am no longer a TC member, but I'm still on the mailing list)
I appreciate your feedback and asking questions that move discussions forward. > If I was a TC member, the first question I would be asking is: what target? > > I believe base-files creates /lib64 -> usr/lib64. Correct? > > What conflicting symlink does systemd create under at least some > circumstances? Is it /lib64 -> usr/lib? I confirm all of the above. > What architectures are affected by this? My reading of #1079329 > is that it potentially affects any architecture that *does not* > have its canonical/interoperable ld.so(8) path in /lib64, so in > particular arm64 is usually affected (because arm64's canonical ld.so > is /lib/ld-linux-aarch64.so.1, so there is no reason why a minimal > arm64 system necessarily needs to contain /usr/lib64) but amd64 is not > (because amd64's canonical ld.so is /lib64/ld-linux-x86-64.so.2, > so every working usr-merged amd64 system must already contain > /usr/lib64/ld-linux-x86-64.so.2). > > If https://wiki.debian.org/ArchitectureSpecificsMemo is accurate, the > loong64, mips64el, ppc64* and sparc64 architectures are in the same > equivalence class as amd64 (/lib64 exists as ABI), and all other known > official and -ports architectures are in the same equivalence class > as arm64. I confirm your understanding. The equivalence class of amd64 is entirely unaffected by this, because it always contains /usr/lib64 and in that case, the link that systemd creates is compatible with base-files. To see how this setup may pose practical problems, consider using an ARM64 laptop. This system usually lacks /usr/lib64 and systemd creates /lib64 -> /usr/lib. Now you install box64 or qemu-user and libc6:amd64 to run some amd64 application. This will not update /lib64 as it already exists. Executing the binary now fails, because /lib64/ld-linux-x86-64.so.2 does not exist. We installed it to /usr/lib64 trusting that the symlink would make it visible in the required location. This very much is a Debian-specific problem, because Debian is the root of the only Linux distribution hierarchy that does multiarch and allows pretty much arbitrary combinations of architectures. Everywhere else you'd rather set up a container where there would be a separate /lib64 that systemd would setup in a different way. The systemd assumption here is that /lib64 can be architecture-dependent, but that assumption is rendered invalid by multiarch. I think there is one more way out here. We may choose to install /usr/lib64 as a symlink to lib (e.g. in base-files' data.tar) and then move ld-linux-x86-64.so.2 to /usr/lib in libc6:amd64. At that point, we no longer care whether /lib64 points to /usr/lib64 or /usr/lib (both work equally well). This actually is rather close to what Arch Linux does. Going this route requires killing multilib as the multilib libraries (e.g. libc6-amd64:i386) would then collide with system libraries. I don't think I'd miss multilib as our cross toolchains have matured significantly, but I expect others to disagree and you're back to overriding a different developer. As far as I understand it, we may pick any three: * Allow systemd to manage /lib64 as it does. * /usr-move * Multiarch * Multilib No matter how you choose here, one of these will be broken. Helmut
