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

[Helmut Grohne]

Control: tags -1 - moreinfo

What further information do you require exactly?

On Tue, Oct 08, 2024 at 11:15:00PM +0100, Luca Boccassi wrote:
> That's correct, as the dynamic loader is at /usr/lib/ld-linux-
> aarch64.so.1 and the symlink will be created to the first directory
> between /usr/lib64 and /usr/lib that exists and has the loader, in that
> order.
> 
> So it seems to me either base-files needs to be able to deal with this,
> or the loader should be symlinked in /usr/lib64 (like Fedora does)?

I see no technical reason for base-files to deal with packages messing
with /lib64 symlinks. The pending policy change forbids doing so and you
seconded it.

I also see no reason to add the loader to /usr/lib64 as nothing
references that path nor any reason for having /lib64 on arm64 in the
first place.

Please clarify what kind of problem is being solved on the systemd side
in attempting to manage a /lib64 symlink. I can partially answer this
question myself: systemd supports "hermetic /usr" which amounts to
bootstrapping an installation from a bare /usr tree. As such, it
contains code to manage locations outside /usr and that happens to
include aliasing symlinks. What I do not see is why it has to manage
/lib64 on arm64. It could simply stop doing so and all would be good as
far as I can see. Let us pretend systemd upstream were to drop the code
for creating /lib64 on arm64. Which users would complain?

Helmut