[systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf

[Kay Sievers]

On Mon, Jun 30, 2014 at 9:35 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Mon, 30.06.14 21:28, Kay Sievers (kay at 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