Bug#1091995: tech-ctte: clarify authority of aliasing symbolic links
On Fri, 03 Jan 2025 at 10:02:43 +0100, Helmut Grohne wrote:
> Hello committee members,
(I am no longer a TC member, but I'm still on the mailing list)
> In particular,
> systemd assigns a different link target [for /lib64] than base-files does
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?
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.
smcv
Reply to: