On Thu, 10 Oct 2024 at 21:08, Helmut Grohne <hel...@subdivi.de> wrote: > > Hi Luca, > > On Thu, Oct 10, 2024 at 11:35:17AM +0100, Luca Boccassi wrote: > > Sorry, but I am still not following. I do not understand, why would > > lib64 not be needed? It's a 64bit architecture, no? If I download a > > Fedora 40 aarch64 image from: > > > > https://fedoraproject.org/server/download > > > > and check the root directory, this is what I see: > > > > total 16 > > dr-xr-xr-x. 2 root root 6 Jan 24 2024 afs > > lrwxrwxrwx. 1 root root 7 Jan 24 2024 bin -> usr/bin > > drwxr-xr-x. 2 root root 6 Apr 15 00:02 boot > > drwxr-xr-x. 2 root root 6 Apr 15 00:02 dev > > drwxr-xr-x. 121 root root 8192 Apr 15 00:26 etc > > drwxr-xr-x. 2 root root 6 Jan 24 2024 home > > lrwxrwxrwx. 1 root root 7 Jan 24 2024 lib -> usr/lib > > lrwxrwxrwx. 1 root root 9 Jan 24 2024 lib64 -> usr/lib64 > > drwxr-xr-x. 2 root root 6 Jan 24 2024 media > > drwxr-xr-x. 2 root root 6 Jan 24 2024 mnt > > drwxr-xr-x. 2 root root 6 Jan 24 2024 opt > > drwxr-xr-x. 2 root root 6 Apr 15 00:02 proc > > dr-xr-x---. 3 root root 126 Apr 15 00:27 root > > drwxr-xr-x. 2 root root 6 Apr 15 00:02 run > > lrwxrwxrwx. 1 root root 8 Jan 24 2024 sbin -> usr/sbin > > drwxr-xr-x. 2 root root 6 Jan 24 2024 srv > > drwxr-xr-x. 2 root root 6 Apr 15 00:02 sys > > drwxrwxrwt. 2 root root 6 Apr 15 00:02 tmp > > drwxr-xr-x. 12 root root 144 Apr 15 00:03 usr > > drwxr-xr-x. 20 root root 4096 Apr 15 00:12 var > > Sorry, but I am still not following. I do not understand, why would > lib64 be needed. You detail how it is being created, but there is no > implication from creation to need. We discover unused files all the > time. If I create a Debian arm64 sid chroot using mmdebstrap, it is not > there. Quite obviously, there is no universal need for /lib64 on 64bit > architectures. There still may be a conditional need whose nature we do > not understand yet.
But how can you be sure that nothing depends on it? How have you checked that it's not needed? This logic has been there for many years > There is one obvious way in which multilib aliasing links are required. > That's when the path of the dynamic loader requires them. We have a wiki > page documenting this: https://wiki.debian.org/ArchitectureSpecificsMemo > > * amd64 -> lib64 > * loong64 -> lib64 > * mips64el -> lib64 > * ppc64 -> lib64 > * ppc64el -> lib64 > * s390x -> lib64 > * sparc64 -> lib64 > * x32 -> libx32 > > These are the cases where systemd really should check for aliasing links > of multilib directories and create them if missing. In particular, it > should only ever point them at the corresponding location. Even your > Fedora example has /lib64 point at usr/lib64 and not usr/lib. It is the > /lib64 -> usr/lib link that this bug takes issue with and that systemd > must not create. > > Generally speaking, the use of multilib paths for dynamic loaders is > deprecated and new architectures should use plain /lib and use a unique > name therein. loong64 is recent, but they utterly failed at > communicating and hence followed the bad example. In particular, arm64 > is not on the list. > > As a consequence, I think systemd needs to change in two ways: > * It should never create non-matching aliasing links (such as /lib64 -> > usr/lib). As above > * When the link target (e.g /usr/lib64) does not exist, it should not > create the aliasing symlink. This is already the case
