[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:22 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Mon, 30.06.14 20:38, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
>
>>
>> On Mon, Jun 30, 2014 at 11:10:15AM -0700, Lennart Poettering wrote:
>> > +                        <varlistentry>
>> > +                                <term><filename>/usr/lib</filename></term>
>> > +                                <listitem><para>System libraries and
>> > +                                package-specific
>> > +                                data.</para></listitem>
>> > +                        </varlistentry>
>> > +
>> > +                        <varlistentry>
>> > +                                <term><filename>/usr/lib64</filename></term>
>> > +                                <listitem><para>Secondary library
>> > +                                directory for placing 64bit versions
>> > +                                of system libraries in, if the primary
>> > +                                architecture of the system is
>> > +                                32bit. This directory should not be
>> > +                                used for package-specific data, unless
>> > +                                this data requires 64bit-specific
>> > +                                versions, too.</para></listitem>
>> > +                        </varlistentry>
>>
>> So far systemd was agnostic to the details of this split. This makes
>> this official, and conflicts with the Debian/Ubuntu camp. The
>> "multiarch" layout is more flexible, so this seems backwards.
>
> I do agree that the Debian/Ubuntu design here sounds like the better
> design there than Fedora's lib64. But then again lib64 is encoded in the
> ELF ABI since the dynamic loader is located there. There's no way we can
> get rid of it.

Right, we will have /lib64, but we do not need /usr/lib64/

> 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.

> 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.

We should find out when we need to create /lib64 --> $libdir, grr ... :)

Kay