Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 2:38 PM, Lennart Poettering wrote: >> 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, 30.06.14 12:56, Filipe Brandenburger (filbran...@google.com) wrote: > > Hi, > > On Mon, Jun 30, 2014 at 12:28 PM, Kay Sievers wrote: > > 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 -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, 30.06.14 21:35, Lennart Poettering (lenn...@poettering.net) wrote: > On Mon, 30.06.14 21:28, Kay Sievers (k...@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. 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 -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 09:02:07PM +0100, Simon McVittie wrote: > On 30/06/14 20:56, Filipe Brandenburger wrote: > > On Mon, Jun 30, 2014 at 12:28 PM, Kay Sievers wrote: > >> 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 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On 30/06/14 20:56, Filipe Brandenburger wrote: > On Mon, Jun 30, 2014 at 12:28 PM, Kay Sievers wrote: >> 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 9:35 PM, Lennart Poettering wrote: > On Mon, 30.06.14 21:28, Kay Sievers (k...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, 30.06.14 21:28, Kay Sievers (k...@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?), how would you decide when to create it? #idef __x86_64__? And then always link it to $libdir? > > 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 -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 9:22 PM, Lennart Poettering wrote: > 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: >> > + >> > +/usr/lib >> > +System libraries and >> > +package-specific >> > +data. >> > + >> > + >> > + >> > + >> > /usr/lib64 >> > +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. >> > + >> >> 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
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: > > + > > +/usr/lib > > +System libraries and > > +package-specific > > +data. > > + > > + > > + > > + > > /usr/lib64 > > +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. > > + > > 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
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 8:38 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jun 30, 2014 at 11:10:15AM -0700, Lennart Poettering wrote: >> + >> +/usr/lib >> +System libraries and >> +package-specific >> +data. >> + >> + >> + >> +/usr/lib64 >> +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. >> + > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 11:10:15AM -0700, Lennart Poettering wrote: > + > +/usr/lib > +System libraries and > +package-specific > +data. > + > + > + > +/usr/lib64 > +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. > + 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
