Hi Luca, On Wed, Oct 09, 2024 at 04:20:25PM +0100, Luca Boccassi wrote: > On Wed, 9 Oct 2024 at 15:35, Helmut Grohne <hel...@subdivi.de> wrote: > > On Wed, Oct 09, 2024 at 12:28:03PM +0100, Luca Boccassi wrote: > > > 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. > > > > Thanks for confirming. Please go ahead and remove the creation of /lib64 > > from systemd then. > > Sorry, I do not follow. As mentioned, this cannot just be removed.
You appeared to agree with my general description of the mechanism. You detailed that systemd needs to create these links when needed at runtime, but for arm64 there is no known nor documented need for /lib64, so I read that as you agreeing the /lib64 link on arm64 should be removed upstream. If you believe that it cannot be removed, please give details why you think so. If you insist on cargo culting this code, there is another way. We know for a fact that in the hermetic-/usr case, there is no package manager on whose toes systemd could step. In particular, there is no /var/lib/dpkg. So systemd could simply check that location and skip bothering with aliasing links if it exists. Thus we would turn the broken code in systemd into dead code on Debian systems until you transform the installation hermetic and then it would return. Helmut
