[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: