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. 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). * When the link target (e.g /usr/lib64) does not exist, it should not create the aliasing symlink. If it follows these two rules, it should be good even creating /lib64 on arm64 even on Debian with no matching on the package manager. It'll also continue creating the aliasing link on Fedora whose existence (though not need) you demonstrated. Helmut
