[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigelt weig...@metux.de wrote: * Micha?? Górny mgo...@gentoo.org schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? Isn't it also a question of making sure the new rootfs is initfs metaphor will always work, which requires all the standard utilities, plus any admin stuff that might be required, to be available in cases of system-recovery? The latter is already somewhat nebulous for a lot of people, which is why it's nice when distributions do it for you (traditionally by making tools available on the rootfs.) Point is, those utilities all need to be kept up to date with any changes in the underlying packages, which adds another layer of complexity (and may require some static builds.) -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Michał Górny wrote: On Tue, 10 Jan 2012 12:56:11 -0600 Dale rdalek1...@gmail.com wrote: How much time does it take when the initramfs fails? The same when rootfs fails? Only the fact that initramfs is less likely to break than rootfs, Seems to me for the average desktop user (who all this is aimed at, a narrowing of scope which smacks of poor design) both partitions will be on the same drive, so I don't know what you base that assertion on. and you have a pretty good opportunity now to experiment with it Except we only have the tools we thought to include on the initramfs, not everything our nice distro system packagers, who have experience and feedback over a much broader spectrum than one user, provide for us on root. I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. The mess was created by people shouting 'hey, real men use separate /usr for no good reason! Be awesome like us'. No, it was created by coders not really grokking why people used /usr, finding it made integration tricky with dependent projects and then saying oh well no-one has a good reason for a separate /usr, let's just ban it. Now the stance has changed to a separate /usr can be cool for snapshots, let's move *everything* there. The shifting nature of the arguments and the solutions makes me more uncomfortable that this hasn't been thought through even with the amount of feedback, and more importantly proper consideration to that feedback, required for a GLEP, let alone a change to base Linux filesystem specifications. Blanket dismissals of any conflicting opinion only worsens that feeling. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Tue, Jan 17, 2012 at 5:15 PM, Steven J Long sl...@rathaus.eclipse.co.uk wrote: The shifting nature of the arguments and the solutions makes me more uncomfortable that this hasn't been thought through even with the amount of feedback, and more importantly proper consideration to that feedback, required for a GLEP, let alone a change to base Linux filesystem specifications. Keep in mind that the main proponents of this do not intend to issue any GLEPs (they don't use Gentoo), and they may or may not get around to changing FHS/etc. They just intend to do it - and to some extent they're already doing it. Unless projects like udev get forked, we're going there whether we want to or not - apparently a soon-to-be-introduced version of udev already breaks when /usr isn't mounted at boot. If people don't like this, they need to start writing code, otherwise they're going to get it by default... Rich
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
* Olivier Cr?te tes...@gentoo.org schrieb: You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. That's one of the reasons why Fedora is so bad, that I must refuse to use it in critical enterprise systems (same as RHEL). It already was ugly about 5 years ago (while SuSE is ranking 1 you-really-dont-wanna-use-it distros since about 10 years) Please, don't let Gentoo become as bad as Fedora, RHEL or SLES. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
* Olivier Cr?te tes...@gentoo.org schrieb: d-bus is not high-level stuff... For example, you can't use bluetooth without d-bus. Even Android has it.. really sad, that so many important packages are depending on that misdesigned bloat. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 19:30:07 +0100 Marc Schiffbauer msch...@gentoo.org wrote: * Olivier Crête schrieb am 04.01.12 um 18:40 Uhr: On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Here is a prime example of why vertical integration should really be called a horrible mess of tight coupling... You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. IMO a system should *always* be bootable without that high level stuff. And by bootable I mean that you can get a root prompt at least. And why do you consider D-Bus being high-level? Just because things used to reinvent the wheel before in a much worse fashion? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
* Michał Górny schrieb am 05.01.12 um 09:26 Uhr: On Wed, 4 Jan 2012 19:30:07 +0100 Marc Schiffbauer msch...@gentoo.org wrote: * Olivier Crête schrieb am 04.01.12 um 18:40 Uhr: On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Here is a prime example of why vertical integration should really be called a horrible mess of tight coupling... You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. IMO a system should *always* be bootable without that high level stuff. And by bootable I mean that you can get a root prompt at least. And why do you consider D-Bus being high-level? Just because things used to reinvent the wheel before in a much worse fashion? I meant hight-level only in a way that it is not really needed to boot the very basic things of a system so that I can get a root prompt at the console at least. E.g. you do not need dbus to find and mount the rootfs, fire a getty and shell. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgp25u9OqPf4y.pgp Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 12:08 +0100, Marc Schiffbauer wrote: I meant hight-level only in a way that it is not really needed to boot the very basic things of a system so that I can get a root prompt at the console at least. E.g. you do not need dbus to find and mount the rootfs, fire a getty and shell. Obviously, you can do init=/bin/sh, that's doesn't help you much. I think we're all speaking of a minimually useful system here. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 12:08 +0100, Marc Schiffbauer wrote: I meant hight-level only in a way that it is not really needed to boot the very basic things of a system so that I can get a root prompt at the console at least. E.g. you do not need dbus to find and mount the rootfs, fire a getty and shell. Obviously, you can do init=/bin/sh, that's doesn't help you much. I think we're all speaking of a minimally useful system here. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Olivier Crête posted on Thu, 05 Jan 2012 09:31:07 -0500 as excerpted: On Thu, 2012-01-05 at 12:08 +0100, Marc Schiffbauer wrote: I meant hight-level only in a way that it is not really needed to boot the very basic things of a system so that I can get a root prompt at the console at least. E.g. you do not need dbus to find and mount the rootfs, fire a getty and shell. Obviously, you can do init=/bin/sh, that's doesn't help you much. I think we're all speaking of a minimally useful system here. But init=/bin/sh (or /bin/bash as I use here) DOES help in a surprising number of cases as long as the necessary storage and input drivers and filesystem modules are builtin. And a lot of us have strong ideas about wanting to keep it that way, being able to use init=/bin/sh on the kernel command line itself, from grub or whatever. Some of us even tried lvm and dumped it for precisely that reason: it requires userspace and thus an initr* if root is on lvm, and without an lvm managing root, its usefulness is diminished to the point where it's more trouble than it's worth, especially since md/raid has handled partitioned RAID very well for quite some time now (a big use case for lvm originally, since md/raid didn't handle partitioned mds directly, back in the day), AND unlike lvm, it can be configured on the kernel command line directly, allowing one to actually get to that init=/bin/sh if necessary. That's low level. Tell me when init=/usr/bin/dbus-whatever works from the kernel command line. Until then, system-bus or no-system-bus, it's not even in the same ball park, or even on the same planet, come to think of it, level-wise. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Thu, 5 Jan 2012 17:12:26 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: But init=/bin/sh (or /bin/bash as I use here) DOES help in a surprising number of cases as long as the necessary storage and input drivers and filesystem modules are builtin. And a lot of us have strong ideas about wanting to keep it that way, being able to use init=/bin/sh on the kernel command line itself, from grub or whatever. [...] That's low level. Looking at your definition of 'low level', it seems that OpenRC is high level as well. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Michał Górny wrote: On Sun, 1 Jan 2012 08:53:26 + Sven Vermeulen sw...@gentoo.org wrote: On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote: The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My understanding is that they want to move software that is installed in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move everything from /lib to /usr/lib. I don't like this one bit. Things used to be simple with the split between /bin and /usr/bin (and its related directories), this isn't going to make it more simple. Simple? Should I start requesting additional packages moved into rootfs because I feel like needing them? Things can and will go more ugly, and I wouldn't be surprised if anytime soon people will start complaining because they ran out of space on their rootfs. Well, it is conceptually quite simple: if it's needed in single-user mode to get your system up and running again, it belongs in rootfs, and if it isn't, then leave it in user-land. The thing I don't understand is why it is necessary to move stuff from /bin to /usr/bin. After all, if you're running the approved setup you don't have a separate /usr so all the binaries are available from the get-go. What does moving them enable that can't be done now? Sure, if you have binaries in /bin that link to libraries in /usr/lib that could be an issue, but only if you're running with a separate /usr and don't have it mounted when udev starts. So again, not the approved setup, and something you as an admin already have to deal with by making sure /usr is mounted when udev starts (either via an initramfs, or by a tweak to udev startup scripts[1].) wrt GNU coreutils installing to /usr by default, that's so of every GNU package, since they default to a prefix of /usr/local and it's up to a distro (or the end-user) to configure them differently; in general the package assumes it's an addition to the system, unless told otherwise. (Additionally I'd say that binaries installed to /bin that require libraries installed to /usr is a bug, but something that should be dealt with separately. Though with the direction people seem to think is needed, I'm not sure how much effort anyone will put into that.) [1] http://forums.gentoo.org/viewtopic-p-6866484.html -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 8:50 AM, Steven J Long sl...@rathaus.eclipse.co.uk wrote: The thing I don't understand is why it is necessary to move stuff from /bin to /usr/bin. After all, if you're running the approved setup you don't have a separate /usr so all the binaries are available from the get-go. Where is this approved setup documented? Consider guides like this one: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml While you're fixing that you might want to write up an easy migration guide for anybody who followed our official docs in the past (with the past including up to the moment that the raid+lvm guide is updated)... Sure, if you have binaries in /bin that link to libraries in /usr/lib that could be an issue, but only if you're running with a separate /usr and don't have it mounted when udev starts. So again, not the approved setup, and something you as an admin already have to deal with by making sure /usr is mounted when udev starts (either via an initramfs, or by a tweak to udev startup scripts[1].) Well, it is hard to think of a meaningful raid+lvm configuration that doesn't require an initramfs of some sort with the dependence on files in /usr during boot. So, getting our initramfs options improved and supporting this configuration just makes sense regardless before we unmask newer versions of udev. Raid+lvm isn't exactly an unusual use-case. Many distros actually use at least lvm by default now. Rich
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Here is a prime example of why vertical integration should really be called a horrible mess of tight coupling... Remember how people used to make fun of Windows when it would fail to boot if you broke Internet Explorer? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 15:54:07 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Considering that I really thought about stripping that one because otherwise people will not even notice the other page of results. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Here is a prime example of why vertical integration should really be called a horrible mess of tight coupling... You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. -- Olivier Crête tes...@gentoo.org Gentoo Developer
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 04 Jan 2012 12:40:10 -0500 Olivier Crête tes...@gentoo.org wrote: On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Here is a prime example of why vertical integration should really be called a horrible mess of tight coupling... You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. No, I realise full well that some GnomeOS developers would like us to think that HAL, D-BUS, network-manager, udev-extras etc are part of the system, and are sloppily writing code that makes that assumption. However, the question ultimately under discussion is whether Gentoo is to be a Linux distribution or a GnomeOS distribution. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
* Olivier Crête schrieb am 04.01.12 um 18:40 Uhr: On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Here is a prime example of why vertical integration should really be called a horrible mess of tight coupling... You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. If this was true, we will soon have problems with linux systems that windows had in 1995. IMO a system should *always* be bootable without that high level stuff. And by bootable I mean that you can get a root prompt at least. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpHP0cF1oZ61.pgp Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 19:30 +0100, Marc Schiffbauer wrote: * Olivier Crête schrieb am 04.01.12 um 18:40 Uhr: On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Here is a prime example of why vertical integration should really be called a horrible mess of tight coupling... You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. If this was true, we will soon have problems with linux systems that windows had in 1995. IMO a system should *always* be bootable without that high level stuff. And by bootable I mean that you can get a root prompt at least. d-bus is not high-level stuff... For example, you can't use bluetooth without d-bus. Even Android has it.. That said, in the new systemd world, bash is.. Since it's only a UI tools (just like gnome-shell for example). Since you don't need it to boot. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
* Olivier Crête schrieb am 04.01.12 um 19:53 Uhr: On Wed, 2012-01-04 at 19:30 +0100, Marc Schiffbauer wrote: * Olivier Crête schrieb am 04.01.12 um 18:40 Uhr: On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Here is a prime example of why vertical integration should really be called a horrible mess of tight coupling... You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. If this was true, we will soon have problems with linux systems that windows had in 1995. IMO a system should *always* be bootable without that high level stuff. And by bootable I mean that you can get a root prompt at least. d-bus is not high-level stuff... For example, you can't use bluetooth without d-bus. Even Android has it.. And you need bluetooth to boot your stable datacenter server systems? That said, in the new systemd world, bash is.. Since it's only a UI tools (just like gnome-shell for example). Since you don't need it to boot. Yeah right. Having dbus for bluetooth is much more important than having a shell. Please remember that there are *way* more server systems running linux without any graphical desktop at all than desktop systems. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpWXb157aI0g.pgp Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 21:45 +0100, Marc Schiffbauer wrote: That said, in the new systemd world, bash is.. Since it's only a UI tools (just like gnome-shell for example). Since you don't need it to boot. Yeah right. Having dbus for bluetooth is much more important than having a shell. Please remember that there are *way* more server systems running linux without any graphical desktop at all than desktop systems. Please remember that servers and desktops are dwarfed by the number of embedded systems running Linux. Probably more devices are sold running Linux in a single day than the total number of servers in the world... But well, this isn't a number's game. D-Bus is the system bus and bluetooth is just one example of a system level component that uses it. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
* Olivier Crête schrieb am 04.01.12 um 22:55 Uhr: On Wed, 2012-01-04 at 21:45 +0100, Marc Schiffbauer wrote: That said, in the new systemd world, bash is.. Since it's only a UI tools (just like gnome-shell for example). Since you don't need it to boot. Yeah right. Having dbus for bluetooth is much more important than having a shell. Please remember that there are *way* more server systems running linux without any graphical desktop at all than desktop systems. Please remember that servers and desktops are dwarfed by the number of embedded systems running Linux. Probably more devices are sold running Linux in a single day than the total number of servers in the world... Yes, but these do most propably never run some stock distro. But well, this isn't a number's game. D-Bus is the system bus and bluetooth is just one example of a system level component that uses it. ... which is not really required to boot a system. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgplq0ahIKQFg.pgp Description: PGP signature
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Marc Schiffbauer posted on Wed, 04 Jan 2012 21:45:35 +0100 as excerpted: Please remember that there are *way* more server systems running linux without any graphical desktop at all than desktop systems. So with Google activating ~800k android Linux systems a day last I heard, how do the number of (android) Linux systems (which we've already established as having dbus) compare to the number of server Linux systems? If traditional gnu-linux isn't a minority in its own community already, it soon will be. I sympathize with the sentiment behind the argument, but the numbers game really doesn't cut it, or we'd all be running some binary distribution or other instead of from-source Gentoo and we'd not be having this discussion as it would have already been had for us. (Yeah, there IS rather a lot to be read between THOSE lines!) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On 01/01/12 05:15 AM, Zac Medico wrote: Overall, a migration like this should go pretty smoothly as long as people with separate /usr take appropriate actions to make sure their systems will boot. People without separate /usr can basically relax and enjoy the ride. If a separate /usr is the only holdback, would it not be possible to simply add static devnodes to the pre-udev /dev , and make a pre-init wrapper script that mounts /usr ? I know that the genkernel initramfs more or less does this (except that it only attempts to mount 'root' instead of /usr, iirc), but it wouldn't be hard to implement this behaviour in the main system either.. In fact, it would probably be possible to emerge a small package that would do this very thing (although getting behind a udev-controlled /dev might be tricky at emerge-time -- it would need to have a rather heavy pkg-postinst).
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On 03-01-2012 10:51:00 -0600, William Hubbs wrote: If a separate /usr is the only holdback, would it not be possible to simply add static devnodes to the pre-udev /dev , and make a pre-init wrapper script that mounts /usr ? I've thought about this, but a wrapper script assumes that the things it needs are still available in /, so any wrapper script we make will break as soon as something it needs migrates to /usr. For example, consider what happens when bash or all of coreutils migrate to /usr. Do you mean us, or upstream? I don't think bash or coreutils do that. We explicitly configure them with --prefix=/ or move some utils back and forth. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On 03/01/12 11:51 AM, William Hubbs wrote: For example, consider what happens when bash or all of coreutils migrate to /usr. ..well, when /bin/sh no longer exists then there -will- be issues, system-wide, on a massive scale. Unless shells or environments can dynamically map that hash-bang to an appropriate interpreter (ie, themselves) automatically. *shudder*.. I don't even want to think about the migration i'd have to do to handle that change.
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Ian Stakenvicius posted on Tue, 03 Jan 2012 12:03:32 -0500 as excerpted: On 03/01/12 11:51 AM, William Hubbs wrote: For example, consider what happens when bash or all of coreutils migrate to /usr. ..well, when /bin/sh no longer exists then there -will- be issues, system-wide, on a massive scale. Unless shells or environments can dynamically map that hash-bang to an appropriate interpreter (ie, themselves) automatically. *shudder*.. I don't even want to think about the migration i'd have to do to handle that change. FWIW, I was reading a review of [was it GOBO Linux?, some distro that's famous for reorganizing things much like MS does, a program files dir, etc], and it was said to still contained a /bin with only a couple symlinks, /bin/bash and /bin/sh, for this very reason. Of course fedora uses an initr* so real-root and /usr will be mounted at the same time, and they're doing a /bin - /usr/bin symlink at least for now, so they don't need to worry about that in the short term either. Longer term, possibly they'll try to get rid of it, but I expect at least some form of /bin/sh and/or /bin/bash symlink to remain around for quite some time. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Ian Stakenvicius posted on Tue, 03 Jan 2012 10:53:45 -0500 as excerpted: Has the LFH been updated?? Googling seems to say no, as the last mod seems to have been in 2004... That was covered here in the last discussion. The FHS and LSB are getting updated too, with the people driving the update being the very same people, the fedora/redhat folks behind udev/udisks/upower/dbus/ systemd/etc, with gnome as well now talking about a gnomeos that integrates and requires the whole set, plus X (or whatever the X successor is called, I forgot ATM) and gnome, of course, so that future gnome will assume systemd, etc, as well. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Ian Stakenvicius posted on Tue, 03 Jan 2012 11:40:02 -0500 as excerpted: Side note - if /lib is getting moved, does that mean /lib/modules is moving to /usr/lib/modules too? So kernel modules are no longer on root? Yes. Again, the whole thing is being designed from the perspective of a binary distro which already uses an initr* to handle loading the modules necessary for mounting real-root, and from that perspective, all they're doing is having it handle /usr in the same way, mounting it right after real-root in early-init, before control switches to it from the initr*. The set of folks behind this don't particularly care about anyone doing it a different way, which they consider Unix legacy, just as they consider the BSDs, etc, legacy, integrating Linux-only solutions and refusing to hold up progress (as they view it) just because someone else can't keep up. What we're really seeing now is the effect of letting RedHat with its paid developers be the core behind so many core Linux systems, forcing udev, systemd, /usr-as-the-new-root, etc, down everyone else's throats because they can, because the entire community is so dependent on RedHat (with Ubuntu and SuSE as well for some but not all of it) and its devs and its money that it's no longer feasible for anyone else to fork all the core programs RedHat devs lead on, and keep up. Sure, they could be forked, but the forks would be left with few enough resources it'd be like xfree86, they might still be there but in a few years they'd be forgotten about by the rest of the community... One project, not a problem, all of them together, just not feasible. What about when glibc also begins to assume everything's in /usr/? ... -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Tue, Jan 03, 2012 at 05:35:51PM +, Duncan wrote: Ian Stakenvicius posted on Tue, 03 Jan 2012 12:03:32 -0500 as excerpted: On 03/01/12 11:51 AM, William Hubbs wrote: For example, consider what happens when bash or all of coreutils migrate to /usr. ..well, when /bin/sh no longer exists then there -will- be issues, system-wide, on a massive scale. Unless shells or environments can dynamically map that hash-bang to an appropriate interpreter (ie, themselves) automatically. *shudder*.. I don't even want to think about the migration i'd have to do to handle that change. FWIW, I was reading a review of [was it GOBO Linux?, some distro that's famous for reorganizing things much like MS does, a program files dir, etc], and it was said to still contained a /bin with only a couple symlinks, /bin/bash and /bin/sh, for this very reason. Of course fedora uses an initr* so real-root and /usr will be mounted at the same time, and they're doing a /bin - /usr/bin symlink at least for now, so they don't need to worry about that in the short term either. Longer term, possibly they'll try to get rid of it, but I expect at least some form of /bin/sh and/or /bin/bash symlink to remain around for quite some time. Yes, the symlinks will be around for some time for this reason, but, /bin/sh will point to /usr/bin/bash, so you have the same affect if /usr is not mounted since the symlink can't be resolved. William pgp9Uybyu95Nd.pgp Description: PGP signature
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Ian Stakenvicius posted on Tue, 03 Jan 2012 13:18:06 -0500 as excerpted: ... if Gentoo's installed on a system (regardless of platform, and leaving out the Prefix installs), the filesystem is up to gentoo right? ie, there wouldn't be a need for a particular platform to stick with FHS-2.3 would there? Once we migrate to FHS-3.0, we can migrate all archs and profiles at the same time? Filesystem or file hierarchy? At least on Gentoo, the filesystem choice has always been up to the installing admin, but in context I believe you mean file hierarchy. As for archs, I'm not familiar with the minor ones and really only know about x86/amd64, but I don't see any reason the others, possibly with an exception or two that could be single-cased as needed, can't migrate at the same time. I do know some of them get stuck on for instance, older glibc, for long periods, tho, and it wouldn't surprise me at all to have one or more of the minor ones stuck on an old version of something that would either need monkey-patch-backported to deal with the new FHS, or have special-cases for various packages to deal with older layout due to the old versions of one or two packages holding things up for that arch. AFAIK vapier's the gentoo guy with the knowledge there, due to all his work on exotic stuff like superh/sh and the new x32 stuff, or at least he's the one that seems most active in discussions such as this. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Mon, Jan 02, 2012 at 05:39:39AM +, Duncan wrote:
Olivier Crête posted on Sun, 01 Jan 2012 15:17:50 -0500 as excerpted:
On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.
However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.
The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
then create symlinks from the other dirs to /usr/bin.. That can be done
in big move, it's the way Fedora is going to do it.
That's what I had in mind, and in fact have already been thinking about
trying, here.
Which is why I don't really like the idea of packages placing symlinks,
since then it'd likely be the symlink copied last, overwriting the actual
binary with the symlink... pointing at itself due to the symlinked dirs!
If we don't use symlinks at all, we do not have to
force everything in one big move like this, just allow the
package maintainers to update things as new releases come out or do rev
bumps to move their packages. Eventually everything will be off of
/{bin,sbin,lib} and be installed in /usr.
William
pgp9zNKanRc18.pgp
Description: PGP signature
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
William Hubbs posted on Sat, 31 Dec 2011 19:59:47 -0600 as excerpted: a significant change is taking place with several upstreams that will affect us in gentoo[. Boot-critical components such as Udev, kmod, etc], are advocating a major change to the locations where binaries and libraries are stored on linux systems. The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My understanding is that they want to move software that is installed in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move everything from /lib to /usr/lib. If we migrate everything off of the root fs to /usr, all of those solutions become moot. On the other hand, if we don't migrate, we run the risk of eventually having our default configuration not supported by upstream. I see three options: 1) Start migrating packages along with upstream[. Have separate /usr users] start using an initramfs [as previously discussed onlist]. 2) Combine the sbin and bin directories both on the root filesystem and in /usr by moving things from /sbin to /bin and /usr/sbin to /usr/bin. 3) Try to maintain things the way they are as long as possible. Whether or not I like what is happening personally, I think we should consider the first option, because I think it will get more and more difficult for us to do anything else over time. And we will eventually find ourselves not supported by upstreams. I'm for #1 (migrate along with upstream) as well. Gentoo has historically been both light patch, with a policy of staying close to upstream if possible, and customizer's choice, allowing users far more flexibility than most distros. Keeping both goals in mind, migrating with upstream is ultimately the only viable alternative for a whole host of reasons including both staying close to upstream and simple manpower resource issues. That said, we can continue to try to support a separate /usr as long as possible, while switching new installs to the new way and changing the handbook to document it, preferably as soon as possible. Further, as previously discussed, a near-static bare-minimal initramfs that can be configured and forgotten about for long periods over many kernel upgrades should make the switch as painless as possible at least for simple bare- partition installations. As for the switchover, I had already been thinking about it here and thus have a couple ideas I'd very much like to see implemented in portage/PM/ base.eclass that could definitely help, along with a USE flag. I'll call them migrated-rootfs and migrateroot-strict for purposes of discussion, here, and assume they're both portage features and that migrated-rootfs is also a USE flag FEATURES=migrated-rootfs would set a USE-default for migrated-root-to-usr so that it'd default to ON, and would indicate that a user is an early adopter of the new layout, preferring migration as soon as possible. Users could still set the USE flag as desired for specific packages, at least at first, tho at some point it'd probably first be made a profile default, and ultimately profile-masked either on or off. Additionally, FEATURES=migrated-root would expand the collision-protect feature to check for and warn on both same-package and cross-package collisions between related dirs, with all four bin/sbin root/usr dirs checked for name collisions, and both lib dirs (for single lib, additional pairs for multilib) checked as well. Optionally, if implementation is easy enough, have portage simply remove symlinks to identically named files that would otherwise set off the warning. This is a major reason for having it a feature and a USE flag both, since if this is implemented, portage would take preventive action quite apart from whether an ebuild had been updated to use the USE flag or not. FEATURES=migrateroot-strict would make those collision warnings fatal, much like FEATURES=multilib-strict does for its multilib checks. (As an amd64 user who had this feature on for years, until I switched to no- multilib, that's what the idea is based on.) The goal would be to allow early adopter users to set the less strict version and run a --empty-tree @world update, then grep the logs for the warnings it turned on. If none occurred and /usr is either already on the same filesystem or they have the appropriate early-boot measures in place, they could feel reasonably confident about setting up symlinks pointing to the /usr/bin and /usr/lib dirs as appropriate, and could then set FEATURES=migratedroot-strict to ensure it stays clean, since after that any attempted merge that would collide would be fatal. Alternatively users could just set the strict version and see what breaks, instead of grepping the logs for the warnings. Since this would leverage the code already in place and tested for collision-protect and multilib-strict, cross-package checking should be fairly easy to implement, but same-package checking and/or
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On 01/01/2012 01:23 AM, Duncan wrote: As for the switchover, I had already been thinking about it here and thus have a couple ideas I'd very much like to see implemented in portage/PM/ base.eclass that could definitely help, along with a USE flag. I'll call them migrated-rootfs and migrateroot-strict for purposes of discussion, here, and assume they're both portage features and that migrated-rootfs is also a USE flag FEATURES=migrated-rootfs would set a USE-default for migrated-root-to-usr so that it'd default to ON, and would indicate that a user is an early adopter of the new layout, preferring migration as soon as possible. Users could still set the USE flag as desired for specific packages, at least at first, tho at some point it'd probably first be made a profile default, and ultimately profile-masked either on or off. I'm not sure if a USE flag for FEATURES setting would be necessary. If we want to enforce a global policy, then I guess a QA warning would be warranted. Overall, a migration like this should go pretty smoothly as long as people with separate /usr take appropriate actions to make sure their systems will boot. People without separate /usr can basically relax and enjoy the ride. -- Thanks, Zac
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Zac Medico posted on Sun, 01 Jan 2012 02:15:49 -0800 as excerpted: I'm not sure if a USE flag for FEATURES setting would be necessary. If we want to enforce a global policy, then I guess a QA warning would be warranted. I didn't state why I suggested that, but here's the reasoning: Unless I missed an update somewhere, USE flags are covered by PMS and thus available to be used in ebuilds, etc. AFAIK, portage FEATURES are just that, portage FEATURES, and thus are supposed to be opaque to ebuilds, which shouldn't need to care which PM is running or its features, as long as it's PMS compliant. Thus, the split between the FEATURES bit which the ebuild shouldn't need to know about (the user sets up the symlinks and sets the features and portage takes care of it managing the rest for existing versions without rewriting), and the USE flag, for where upstreams and/or ebuilds are actually rewritten with the possibility of both layouts (and later only the /usr locations) in mind and the ebuild installs to the targeted location based on the USE flag. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Sun, Jan 01, 2012 at 09:23:11AM +, Duncan wrote: Gentoo has historically been both light patch, with a policy of staying close to upstream if possible, and customizer's choice, allowing users far more flexibility than most distros. Keeping both goals in mind, migrating with upstream is ultimately the only viable alternative for a whole host of reasons including both staying close to upstream and simple manpower resource issues. That said, we can continue to try to support a separate /usr as long as possible, while switching new installs to the new way and changing the handbook to document it, preferably as soon as possible. In this situation, I don't know how we will be able to support both ways because there is more involved than just where things are installed. Udev 175 is currently masked, because the way it operates has changed enough that it doesn't work correctly if it starts before /usr is mounted, and the failures you find will be very difficult to track down. So, udev isn't only changing where it is installed, but how it runs. Supporting a separate /usr without an initramfs will require one of two things. One possibility is a customization to openrc, which we have been looking at, that would be able to run fsck on /usr and mount /usr all before udev starts. The drawback here is this will only work for openrc users. Another possibility is a script that would run as the init= parameter to the kernel, which would fsck /usr and mount /usr then start the real init process. This would be more generic and would be able to run regardless of whether you are using sysvinit/openrc. Here is the big problem with both of these solutions as I see them. They depend on several pieces of software remaining on the root filesystem, and if/when this software is migrated, we will be back to having this discussion again. Further, as previously discussed, a near-static bare-minimal initramfs that can be configured and forgotten about for long periods over many kernel upgrades should make the switch as painless as possible at least for simple bare- partition installations. I want to look at dracut and see if there is a way to configure it to create a minimal initramfs like you are suggesting, because, if there is we don't need to re-invent the wheel. I don't think your portage feature/use flag suggestion is a good idea, because, right now most of this is about where things are installed, but, eventually we might have to start actually patching software to make it work if it is installed on / instead of /usr, and there is no way to know how much patching we would have to do. What are your thoughts? William pgpDjsJWmAho1.pgp Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
Yeah I know Im replying to my own message, but I wanted to add a
thought about the symbolic links issue.
I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.
However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.
That way, once the package maintainer knows that the symbolic links are
not needed, they can be removed and eventually all of these directories
would be empty and they could eventually be removed if desired.
Thoughts?
William
pgp7ofExXW7iu.pgp
Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
Hi,
On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.
However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.
The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
then create symlinks from the other dirs to /usr/bin.. That can be done
in big move, it's the way Fedora is going to do it.
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Olivier Crête posted on Sun, 01 Jan 2012 15:17:50 -0500 as excerpted:
On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.
However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.
The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
then create symlinks from the other dirs to /usr/bin.. That can be done
in big move, it's the way Fedora is going to do it.
That's what I had in mind, and in fact have already been thinking about
trying, here.
Which is why I don't really like the idea of packages placing symlinks,
since then it'd likely be the symlink copied last, overwriting the actual
binary with the symlink... pointing at itself due to the symlinked dirs!
Which is why I suggested a portage feature that would detect such
collisions and die before installing them, potentially overwriting the
binary with a symlink to itself!
--
Duncan - List replies preferred. No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On 01/01/2012 09:39 PM, Duncan wrote:
Olivier Crête posted on Sun, 01 Jan 2012 15:17:50 -0500 as excerpted:
On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.
However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.
The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
then create symlinks from the other dirs to /usr/bin.. That can be done
in big move, it's the way Fedora is going to do it.
That's what I had in mind, and in fact have already been thinking about
trying, here.
Which is why I don't really like the idea of packages placing symlinks,
since then it'd likely be the symlink copied last, overwriting the actual
binary with the symlink... pointing at itself due to the symlinked dirs!
Which is why I suggested a portage feature that would detect such
collisions and die before installing them, potentially overwriting the
binary with a symlink to itself!
It should not be a problem because merge of symlinks is automatically
delayed in cases when the symlink target doesn't exist yet. There's a
loop where it merges as many regular files as it can, and if there are
any symlinks that can't be resolved then it merges them after all the
regular files have been merged.
--
Thanks,
Zac
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Sat, 31 Dec 2011 19:59:47 -0600 William Hubbs willi...@gentoo.org wrote: Udev, kmod (which is a replacement for module-init-tools which will be needed by =udev-176), systemd, and soon others, are advocating a major change to the locations where binaries and libraries are stored on linux systems. The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My understanding is that they want to move software that is installed in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move everything from /lib to /usr/lib. I coulda swore April was another four months away... -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
