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

[Lennart Poettering]

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.

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.

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?

Lennart

-- 
Lennart Poettering, Red Hat