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
