On Mon, Jun 30, 2014 at 9:35 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Mon, 30.06.14 21:28, Kay Sievers (k...@vrfy.org) wrote: > >> > Note that the concept of lib64 is actually encoded in systemd now, since >> > nspawn and PID 1 when switching roots will actually create /lib64 as >> > symlink to /usr/lib64 should the latter exist. That scheme should be >> > compatible with both Fedora's and Debin's multilib design. >> >> There is only the tuple-dir in /usr, seems, our current factory-setup >> will not work on Debian. We probably should change the logic to >> $libdir instead of looking for /usr/lib64. > > Not following? I mean, the x86-64 ABI practically requires /lib64 to > exist (does any other ABI?)
The ABI defines and requires: /lib64/ld-linux-x86-64.so.2 so /lib64 needs to be a symlink to /usr/lib(something), or a directory containing nothing but the dynloader. > how would you decide when to create it? > #idef __x86_64__? And then always link it to $libdir? I don't know exactly, something along that line. We would probably have configure to find out libdir and tuple-name in some way and try to make sense out of it. >> > I tried to weasel myself out of the situation by clarifying that the the >> > dir should only exist in case of the ABI requiring that. >> > >> > Not sure how we could improve the situation... Suggestions? >> >> I guess we should just not define /usr/lib64, it is just not strictly >> needed vor the ABI or compat. > > THis is so fucking broken. I mean, how should we ever be able to tell > people where to place their stuff if the distros can't even agree on the > ABI... meh. Yeah, it is all completely broken, as broken as the idea to spread the system over many directories and splitting the so-called root from /usr. None of that stuff makes the slightest sense today. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
