Bug#1079329: systemd(?) still creates /lib64 on arm64

[Helmut Grohne]

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