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

[Luca Boccassi]

On Thu, 10 Oct 2024 at 21:08, Helmut Grohne <helmut at 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