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

[Luca Boccassi]

On Wed, 9 Oct 2024 at 07:09, Helmut Grohne <helmut at subdivi.de> wrote:
>
> 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.

As far as I can tell, unless I looked up the wrong thing, the policy
change specifically refers to packages installing files, which is not
what is happening here: the packages are not installing anything,
neither directly nor via maintainer scripts, it's purely a runtime
functionality. And I think it would be wrong if it applied to this
too: this runtime functionality is needed, and you have explained the
use case yourself below, so I do not believe policy should forbid 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

Yes that's the use case, just as you defined it. The problem is that
these links need to exist, and they need to be created at runtime in
an ephemeral root, and the target needs to be figured out <somehow>.
The best we have so far, that has been working fine over the years, is
to target it to where the loader is located. If you think there's a
better way, that works everywhere, please feel free to propose such a
change upstream, via a pull request ideally, or at least via an issue
(but please do note that PRs are better). In the end I think that's
the right place to discuss such details, rather than a downstream bug.