On Mon, 30.06.14 20:38, Zbigniew Jędrzejewski-Szmek (zbys...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
