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

[Zbigniew Jędrzejewski-Szmek]

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

Zbyszek

[Kay Sievers]

On Mon, Jun 30, 2014 at 8:38 PM, Zbigniew Jędrzejewski-Szmek

Post by Zbigniew Jędrzejewski-Szmek

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

It sounds like, yes.

We should not specify the content of the lib64 directory. All we would
need to run an ABI compliant x86_64 system is /lib64 ->
usr/lib/x86_64-linux-gnu/.

What a mess, Fedora should just sort out its backwards and outdated
lib64/ and libexec/ rules and everybody would benefit.

Kay

[Lennart Poettering]

Post by Zbigniew Jędrzejewski-Szmek

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

[Kay Sievers]

On Mon, Jun 30, 2014 at 9:22 PM, Lennart Poettering

Post by Lennart Poettering

Post by Zbigniew Jędrzejewski-Szmek

+ <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/

Post by Lennart Poettering
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.

Post by Lennart Poettering
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

[Lennart Poettering]

Post by Kay Sievers

Post by Lennart Poettering
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?), how would you decide when to create it?
#idef __x86_64__? And then always link it to $libdir?

Post by Kay Sievers

Post by Lennart Poettering
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.

Lennart

[Kay Sievers]

On Mon, Jun 30, 2014 at 9:35 PM, Lennart Poettering

Post by Lennart Poettering

Post by Kay Sievers

Post by Lennart Poettering
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.

Post by Lennart Poettering
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.

Post by Lennart Poettering

Post by Kay Sievers

Post by Lennart Poettering
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

[Lennart Poettering]

Post by Lennart Poettering
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 have not updated the man page so that it only mentions $libdir, and
doesn't codify lib64 in anything.

It's really disappointing that the Linux distributions can't even agree
on where to place libraries. FHS is such a joke... But anyway, the man
page should now not be too far from what the various distribution's
ABIs.

Lennart

[Filipe Brandenburger]

Hi,

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

Problem is that $libdir is relevant for the host distribution but
might not be for the one running inside the nspawn'd namespace.

Consider the case where you're running Fedora but use debootstrap to
create a Debian tree and systemd-nspawn to run a process in it.
$libdir will make sense in Fedora, not in Debian...

Maybe it should try both and figure out which one of them exists?

Or default to $libdir and allow an override for the cross-distro cases.

Cheers,
Filipe

[Simon McVittie]

Post by Filipe Brandenburger

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

Consider the case where you're running Fedora but use debootstrap to
create a Debian tree and systemd-nspawn to run a process in it.
$libdir will make sense in Fedora, not in Debian...

In practice, a debootstrap'd 64-bit Debian tree will have to contain its
own /lib64 basically forever, because the generic x86-64 Linux ABI says
it must (even though Debian does not otherwise use lib64 any more);
libc6_*_amd64.deb contains the directory and the ld-linux-x86-64.so
symlink. As long as you don't actively break an existing /lib64 in the
container, everything should be OK?

On current Debian unstable, the only thing in /lib64 is:

lrwxrwxrwx 1 root root 32 Jun 23 22:30 ld-linux-x86-64.so.2 ->
/lib/x86_64-linux-gnu/ld-2.19.so

S

[Zbigniew Jędrzejewski-Szmek]

Post by Simon McVittie

Post by Filipe Brandenburger

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

Consider the case where you're running Fedora but use debootstrap to
create a Debian tree and systemd-nspawn to run a process in it.
$libdir will make sense in Fedora, not in Debian...

In practice, a debootstrap'd 64-bit Debian tree will have to contain its
own /lib64 basically forever, because the generic x86-64 Linux ABI says
it must (even though Debian does not otherwise use lib64 any more);
libc6_*_amd64.deb contains the directory and the ld-linux-x86-64.so
symlink. As long as you don't actively break an existing /lib64 in the
container, everything should be OK?
lrwxrwxrwx 1 root root 32 Jun 23 22:30 ld-linux-x86-64.so.2 ->
/lib/x86_64-linux-gnu/ld-2.19.so

This is about the case when only /usr is present in the container, and
systemd-nspawn creates the rest of dirs and symlinks in container's /.

Zbyszek

[Lennart Poettering]

Post by Filipe Brandenburger
Hi,

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

Problem is that $libdir is relevant for the host distribution but
might not be for the one running inside the nspawn'd namespace.
Consider the case where you're running Fedora but use debootstrap to
create a Debian tree and systemd-nspawn to run a process in it.
$libdir will make sense in Fedora, not in Debian...
Maybe it should try both and figure out which one of them exists?
Or default to $libdir and allow an override for the cross-distro cases.

Hmm, I am tempted to say that we should add a logic to this that just
checks the few debian-style arch tuples we know of, plus fedora-style
lib64, and if any of them exist, we create a lib64 symlink to them. The
table should be relatively short I think. Ugly that we need this, but
maintainable.

With that in place we should allow cross-distro nspawn I figure.

Lennart

[Filipe Brandenburger]

On Mon, Jun 30, 2014 at 2:38 PM, Lennart Poettering

Post by Lennart Poettering

Post by Filipe Brandenburger
Maybe it should try both and figure out which one of them exists?
Or default to $libdir and allow an override for the cross-distro cases.

Hmm, I am tempted to say that we should add a logic to this that just
checks the few debian-style arch tuples we know of, plus fedora-style
lib64, and if any of them exist, we create a lib64 symlink to them. The
table should be relatively short I think. Ugly that we need this, but
maintainable.
With that in place we should allow cross-distro nspawn I figure.

Sounds good to me.

Filipe