Bug#1091995: tech-ctte: clarify authority of aliasing symbolic links
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
Reply to: