Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote I see three options: 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. 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. 4) Following pointers from Zac Medico and others, I've managed to get Gentoo running with busybox's mdev, instead of udev. See http://archives.gentoo.org/gentoo-user/msg_bc91b392ee0f76376104591cdf7dc5f0.xml Executive summary... look Ma; no udev! In the instructions there, I've set up a revised dev-manager ebuild in an overlay. I've requested the changes to be incorporated into the official ebuild and it appears to have been accepted. See... https://bugs.gentoo.org/show_bug.cgi?id=395319 It should be rolled out eventually, and the overlay won't be necessary. I think I've found one item so far that requires udev. My laptop's graphics chip needs a binary blob from radeon-ucode. That binary blob, in turn, requires the presence of /usr/lib/libudev.so.0 which is a symlink to /usr/lib/libudev.so.0.9.3 (which is also required). I can emerge udev move or copy the 2 files over to /root unmerge udev move or copy the 2 files from /root to /usr/lib/ Note that /usr/lib/ is a symlink to /usr/lib64 on my 64-bit gentoo Please discuss; I want to hear what you think. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Hi Walter, On Tue, Jan 03, 2012 at 04:51:57AM -0500, Walter Dnes wrote: 4) Following pointers from Zac Medico and others, I've managed to get Gentoo running with busybox's mdev, instead of udev. See http://archives.gentoo.org/gentoo-user/msg_bc91b392ee0f76376104591cdf7dc5f0.xml Executive summary... look Ma; no udev! Unfortunately, it isn't going to be as simple as switching away from udev. This move is going to move all software from /bin, /sbin and /lib to /usr/bin and /usr/lib. The end result is going to be that regardless of whether you are using mdev or udev you will have to use an initramfs if /usr is on a separate partition. William pgpKPA7t5mMhB.pgp Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/01/12 03:53 AM, Sven Vermeulen 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. I concurr. I will admit that I've been rather out of touch with what other distros are doing (and have been for ~3-4 years), but combining everything into /usr/bin just seems plain backwards and I am rather shocked that all the distros are moving that way. Has the LFH been updated?? Googling seems to say no, as the last mod seems to have been in 2004... I know that, technically, these are 'userspace' programs in that they aren't kernel-space, but they're still 'system' programs so to me it still makes sense for them to be on the 'system' side of the filesystem hierarchy, doesn't it? 3) Try to maintain things the way they are as long as possible. I'm all for this one. I second this too. IMO, unless the FSSTND matches the new proposal from udev/systemd/etc upstreams, then I think we should stick with what the LFH describes. It may be possible, too, on this basis, to file bugs against the upstreams to enforce compatible behaviour?? Of course, 'as long as possible' may depend a bit on what the timelines are.. I would hope that we can support existing behaviour for at least the next 6+ months? (at least then, if the Mayan calendar's right, the end of the world will keep us from having to implement the change)..
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] rfc: locations of binaries and separate /usr
On 01/03/2012 10:53 AM, Ian Stakenvicius wrote: On 01/01/12 03:53 AM, Sven Vermeulen 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. I concurr. I will admit that I've been rather out of touch with what other distros are doing (and have been for ~3-4 years), but combining everything into /usr/bin just seems plain backwards and I am rather shocked that all the distros are moving that way. Has the LFH been updated?? Googling seems to say no, as the last mod seems to have been in 2004... I know that, technically, these are 'userspace' programs in that they aren't kernel-space, but they're still 'system' programs so to me it still makes sense for them to be on the 'system' side of the filesystem hierarchy, doesn't it? The problem is that one group of developers is ignoring years of history and purpose in the separation of /bin and /usr/bin and the ability of having a separate /usr. This is in the udev development team and they /deliberately/ placed or used some programs in /usr/bin instead /bin and requiring that /usr bee in the root partition. I will note that the historical separation of the /usr stems from the days of user home directories being in /usr/home instead of /home. It is getting to the point that the security aspects of having a read-only mount for userspace executables is being overridden by developer fiat. Lay this one at the RedHat/Fedora developers of udev. -- G.Wolfe Woodbury aka redwo...@gmail.com
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 02/01/12 12:54 PM, William Hubbs wrote: The one thing I haven't figured out yet is whether it is possible to create an initramfs that doesn't have to be updated with every kernel upgrade. I'm not sure if there is dracut-specific issues that would relate to this, but the genkernel initramfs (as long as it didn't include any kernel modules) used to work fine when used against a newer-built kernel--note though that this was probably not 'supported' behaviour. So I expect this to be the case with dracut as well.
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 03 Jan 2012 11:08:09 -0500 G.Wolfe Woodbury redwo...@gmail.com wrote: On 01/03/2012 10:53 AM, Ian Stakenvicius wrote: On 01/01/12 03:53 AM, Sven Vermeulen 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. I concurr. I will admit that I've been rather out of touch with what other distros are doing (and have been for ~3-4 years), but combining everything into /usr/bin just seems plain backwards and I am rather shocked that all the distros are moving that way. Has the LFH been updated?? Googling seems to say no, as the last mod seems to have been in 2004... I know that, technically, these are 'userspace' programs in that they aren't kernel-space, but they're still 'system' programs so to me it still makes sense for them to be on the 'system' side of the filesystem hierarchy, doesn't it? The problem is that one group of developers is ignoring years of history and purpose in the separation of /bin and /usr/bin and the ability of having a separate /usr. This is in the udev development team and they /deliberately/ placed or used some programs in /usr/bin instead /bin and requiring that /usr bee in the root partition. Please, explain to me, how did they do it? As far as I am aware, autotools installs files where it is told to. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 03/01/12 10:10 AM, William Hubbs wrote: Unfortunately, it isn't going to be as simple as switching away from udev. This move is going to move all software from /bin, /sbin and /lib to /usr/bin and /usr/lib. The end result is going to be that regardless of whether you are using mdev or udev you will have to use an initramfs if /usr is on a separate partition. I don't think anyone's asked this yet: Do we NEED to deprecate /bin,/sbin,/usr/sbin,/lib ? I realize that udev/kmod/systemd are moving, but there isn't anything in particular that would require everything else to move, is there? I know that there was a compatibility-symlink discussion and in general it was thought that symlinks would be a bad idea.. but we could, for anything that would be required in /bin,/sbin for mdev AND /usr/bin for the new udev,etc (assuming there would actually be overlap, which I expect there wouldn't be) make the /usr/bin version be a symlink and keep /bin,/sbin,etc. around.. It would work at least as a temporary measure, until the new udev/kmod/systemd becomes the de-facto default? 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?
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
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, Jan 3, 2012 at 11:08 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: It is getting to the point that the security aspects of having a read-only mount for userspace executables is being overridden by developer fiat. Can you clarify what you mean by this? I think the whole reason that RedHat is doing this is so that they can make /usr read-only, so that it only changes when you perform upgrades. I imagine the next step would be to use a trusted boot path and verify that partition when it is mounted. FHS has been brought up - I suspect the upstream projects that are sparking this move are quite aware that they're breaking compliance, so I doubt they're going to care if you file bugs pointing this out. No doubt after the change is made they'll lobby to revise FHS, and at that point since everybody will have gone along with it already there won't be much point in voicing objection. As with anything in FOSS - whoever has the developers gets to decide how things work. Anybody can file bugs or post on mailing lists, but the people writing the code will do what they do... Rich
[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
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, Jan 03, 2012 at 11:40:02AM -0500, Ian Stakenvicius wrote: I don't think anyone's asked this yet: Do we NEED to deprecate /bin,/sbin,/usr/sbin,/lib ? I realize that udev/kmod/systemd are moving, but there isn't anything in particular that would require everything else to move, is there? Well, I don't think everything is going to move immediately. The way I see this happening is, udev/systemd/kmod are moving first, then other upstreams will move their software. If we don't move with them, I'm afraid that we will have more and more customizations to maintain, either in the form of ebuilds using custom build options, or maybe even software patches if programs operate with the assumption that they are installed in /usr. I know that there was a compatibility-symlink discussion and in general it was thought that symlinks would be a bad idea.. but we could, for anything that would be required in /bin,/sbin for mdev AND /usr/bin for the new udev,etc (assuming there would actually be overlap, which I expect there wouldn't be) make the /usr/bin version be a symlink and keep /bin,/sbin,etc. around.. It would work at least as a temporary measure, until the new udev/kmod/systemd becomes the de-facto default? Hmm, I'm not really interested in putting symbolic links in /usr/bin linking to things in /bin or /sbin. I'm not following what that does for us. 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? This is an interesting question. I haven't heard one way or the other what is happening with /lib/modules. William pgpK7Kkk2WEqx.pgp Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Hi, On Mon, 2012-01-02 at 10:41 +0200, Eray Aslan wrote: On 2012-01-01 11:50 PM, Olivier Crête wrote: systemd/dracut/etc handles /usr on its own filesystem just fine. What is required is that /usr must be mounted before the pivot_root away from the initramfs. RedHat made some bad design decisions on RPM (.rpmnew files anyone?) and udev. Udev was probably salvagable before systemd but noone has the motivation or the man-power to manage the huge delta that would result now. It would probably amount to forking udev. So people are following along even if they are unhappy. This is completely unrelated to RPMs. And udev was not developed by RedHat, but by a Gentoo developer who works for Suse, then it was maintained by a Suse dev who just very recently joined RedHat. Plus Redhat did not support in-place upgrades last time I checked. So they don't really care for a lot of problems that are important for us. There is a good reason for that, because in-place upgrades are impossible to do safely (and RedHat customers don't accept weird breakages like Gentoo users do). For example, if you replace a library or even a resource file (like a .ui file for GtkBuilder), the only way to make it work is to make sure that no currently running application is using it. And that just can't happen with system libraries like glibc or system packages like udev or dbus. So the only safe way to upgrade those is to reboot. Regarding the original question, I belive there are 2 issues here: 2. Migrating /bin to /usr/bin, /sbin to /usr/sbin etc. For the second point, we should hold on as long as we deem appropriate. Then reconsider and -most probably- move ahead with the migration. Main point is not to break existing installations by making the move too quickly. Give sysadmins time to to adjust, resize partitions if necessary etc. Do not go for half way solutions (i.e. number 2 in the original email). I don't see what breakage would be caused by a big-bang update (move everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really doubt any system has a /usr so tight that adding the couple things that are in / to /usr/bin would break it.. Btw, this also includes /lib* to /usr/lib*. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 03 Jan 2012 13:50:25 -0500 Olivier Crête tes...@gentoo.org wrote: There is a good reason for that, because in-place upgrades are impossible to do safely (and RedHat customers don't accept weird breakages like Gentoo users do). For example, if you replace a library or even a resource file (like a .ui file for GtkBuilder), the only way to make it work is to make sure that no currently running application is using it. And that just can't happen with system libraries like glibc or system packages like udev or dbus. So the only safe way to upgrade those is to reboot. Uhm... Unix filesystems don't work that way; you can unlink an open file and anything that has that file still opened will continue to work. You're thinking of Windows; Unix supports in-place upgrades just fine. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 03-01-2012 13:02:55 -0600, William Hubbs wrote:
On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote:
I don't see what breakage would be caused by a big-bang update (move
everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really
doubt any system has a /usr so tight that adding the couple things that
are in / to /usr/bin would break it.. Btw, this also includes /lib*
to /usr/lib*.
I think the best way to do this part of it is going to be to just follow
the upstream packages. When they release a new version that installs in
/usr, just allow that to happen. Eventually there will be very little in
/{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
/bin/sh.
What packages would that be? If you're thinking about coreutils, just
trim down the ebuild by not moving some of the tools to /bin. Our
ebuild makes it conform to FHS, not the coreutils buildsystem itself.
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 2012-01-03 at 12:36 -0600, William Hubbs wrote: On Tue, Jan 03, 2012 at 11:40:02AM -0500, Ian Stakenvicius wrote: 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? This is an interesting question. I haven't heard one way or the other what is happening with /lib/modules. I doubt the kernel will move its install location, they're a very conservative bunch. But I heard that kmod will start looking for modules in /usr/lib/modules ... -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 2012-01-03 at 13:02 -0600, William Hubbs wrote:
On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote:
I don't see what breakage would be caused by a big-bang update (move
everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really
doubt any system has a /usr so tight that adding the couple things that
are in / to /usr/bin would break it.. Btw, this also includes /lib*
to /usr/lib*.
I think the best way to do this part of it is going to be to just follow
the upstream packages. When they release a new version that installs in
/usr, just allow that to happen. Eventually there will be very little in
/{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
/bin/sh.
I am not for what fedora is doing with the
/bin-/usr/bin, /sbin-/usr/sbin and /lib-/usr/lib symlinks.
At least the upstreams that work for RedHat and Suse (and that's almost
all system packages) will come to expect that these symlinks exist. For
example, I just heard that kmod will expect kernel modules
in /usr/lib/modules even though the kernel installs them
in /lib/modules.. So yes, upstream will force these symlinks on us too.
A couple years ago, Gentoo was the forward looking distribution, ready
to try radical changes that break existing assumption, like our init
scripts with dependencies or our early use of udev. These days, I see so
much resistance to progress, it makes me sad.
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, Jan 3, 2012 at 1:36 PM, William Hubbs willi...@gentoo.org wrote: Well, I don't think everything is going to move immediately. The way I see this happening is, udev/systemd/kmod are moving first, then other upstreams will move their software. Agreed. If only a few packages have issues we don't have to subject our users to a huge overnight change. We can just move gradually with upstream. Hmm, I'm not really interested in putting symbolic links in /usr/bin linking to things in /bin or /sbin. I'm not following what that does for us. Perhaps we could consider compatibility packages, like a bash-links that just installs a symlink to /usr/bin/bash in /bin. Ideally we'd never create them, but if a package can't be fixed in a straightforward way we could add a link package and then have that package depend on it. Then we can get rid of those links over time as nothing depends on them when upstream catches up. Before anything changes at all we need to have a solution in dracut/etc for mounting /usr. Once that is in place packages can move at any pace we wish, so there is no reason to short-cut QA. Rch
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 03-01-2012 14:19:22 -0500, Olivier Crête wrote: On Tue, 2012-01-03 at 12:36 -0600, William Hubbs wrote: On Tue, Jan 03, 2012 at 11:40:02AM -0500, Ian Stakenvicius wrote: 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? This is an interesting question. I haven't heard one way or the other what is happening with /lib/modules. I doubt the kernel will move its install location, they're a very conservative bunch. But I heard that kmod will start looking for modules in /usr/lib/modules ... Seems they just made it a configure argument though [1]. [1] http://git.profusion.mobi/cgit.cgi/kmod.git/commit/?id=a308abec371364eec8344681cfe1fb50d624e43e -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
2012/1/3 Olivier Crête tes...@gentoo.org: A couple years ago, Gentoo was the forward looking distribution, ready to try radical changes that break existing assumption, like our init scripts with dependencies or our early use of udev. These days, I see so much resistance to progress, it makes me sad. I think the key is to keep huge changes optional to start with. This one feels like it is being pushed upon us. I don't really have a big problem with moving to /usr and all that. However, I do have some concerns with the larger direction that everybody is taking with vertical integration (which this is just a part of). For example, if eventually you can't run gnome without systemd where does that leave bsd gentoo users? Gentoo is about choice, and various upstream efforts are moving in the direction of giving users only one choice - take it or leave it. How do you install KDE and Gnome on the same system when they eventually want different sysvinit implementations. Will the RedHat and Ubuntu of the future have no more in common than Tivo and Android do today? Rich
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 12:06 AM, William Hubbs willi...@gentoo.org wrote: On Tue, Jan 03, 2012 at 11:40:02AM -0500, Ian Stakenvicius wrote: I don't think anyone's asked this yet: Do we NEED to deprecate /bin,/sbin,/usr/sbin,/lib ? I realize that udev/kmod/systemd are moving, but there isn't anything in particular that would require everything else to move, is there? Well, I don't think everything is going to move immediately. The way I see this happening is, udev/systemd/kmod are moving first, then other upstreams will move their software. From what I can make out, *only* udev and systemd are making this a hard-and-fast thing so far. kmod has added a configure argument, and no one else has moved yet. In reality, fedora is patching a lot of packages to make them install in /usr. *If* GNU packages decide to move to /usr, *then* we can contemplate moving. Till then, I say let's just do whatever Debian is doing. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, Jan 03, 2012 at 02:19:39PM -0500, Olivier Crête wrote:
On Tue, 2012-01-03 at 13:02 -0600, William Hubbs wrote:
On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote:
I don't see what breakage would be caused by a big-bang update (move
everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really
doubt any system has a /usr so tight that adding the couple things that
are in / to /usr/bin would break it.. Btw, this also includes /lib*
to /usr/lib*.
I think the best way to do this part of it is going to be to just follow
the upstream packages. When they release a new version that installs in
/usr, just allow that to happen. Eventually there will be very little in
/{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
/bin/sh.
I am not for what fedora is doing with the
/bin-/usr/bin, /sbin-/usr/sbin and /lib-/usr/lib symlinks.
At least the upstreams that work for RedHat and Suse (and that's almost
all system packages) will come to expect that these symlinks exist. For
example, I just heard that kmod will expect kernel modules
in /usr/lib/modules even though the kernel installs them
in /lib/modules.. So yes, upstream will force these symlinks on us too.
I just looked at the commit in kmod for this. It can be worked around
with a ./configure switch until the kernel switches their install
location, so they aren't forcing this one.
William
pgpTwJq1xDj6J.pgp
Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 03-01-2012 13:39:14 -0600, William Hubbs wrote: in /usr/lib/modules even though the kernel installs them in /lib/modules.. So yes, upstream will force these symlinks on us too. I just looked at the commit in kmod for this. It can be worked around with a ./configure switch until the kernel switches their install location, so they aren't forcing this one. Current git even sets the default to , so in fact they went back to just /lib/modules. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 1:05 AM, Rich Freeman ri...@gentoo.org wrote: part of). For example, if eventually you can't run gnome without systemd where does that leave bsd gentoo users? Is Mesa support on BSD really all that up-to-date these days? I don't expect that they keep up with bugfixes that well. For instance, Radeon works best with KMS + Gallium and afaik that has no driver for BSD at all. I don't think GNOME Shell is stable on BSD at all. Gentoo is about choice, and various upstream efforts are moving in the direction of giving users only one choice - take it or leave it. If you're arguing purely on the basis of BSD, I think it's a lost cause. They're so far behind Linux that it's not even funny anymore. How do you install KDE and Gnome on the same system when they eventually want different sysvinit implementations. I doubt that's going to happen, though. No DE other than GNOME is interested in vertical integration. Even if someone is, it's a technical problem to be solved with a technical solution. Every problem in computer science can be solved by adding another layer of indirection. Will the RedHat and Ubuntu of the future have no more in common than Tivo and Android do today? Setting aside the silly parts of comparison you've made, the rest is already true from the user's PoV. The two have drastically different UIs, and their packages are incompatible (rpm vs deb, yum vs apt). If some applications are indeed common between the two, it's no surprise since most of those run on Windows too. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, Jan 03, 2012 at 08:12:06PM +0100, Fabian Groffen wrote:
I think the best way to do this part of it is going to be to just follow
the upstream packages. When they release a new version that installs in
/usr, just allow that to happen. Eventually there will be very little in
/{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
/bin/sh.
What packages would that be? If you're thinking about coreutils, just
trim down the ebuild by not moving some of the tools to /bin. Our
ebuild makes it conform to FHS, not the coreutils buildsystem itself.
Yes, coreutils will have to be reworked in that case. I don't know what
the upstream build system does, but we will have to take a look at it.
I'll have to go through on my system at
least and find all of the ebuilds that install things in
/{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
released; this will list all of the things we need to do to complete the
migration.
Basically I have these in my head:
* mask udev-176 in the tree.
* figure out and document how to make a simple initramfs with dracut.
* unmask udev 176 making sure to point users with a separate /usr
partition to how to make an initramfs (I could probably do this with
ewarns in the ebuild and maybe a news item before we go stable).
* stabilize a version of dracut.
* stabilize =udev-176 and kmod.
* Now start stabilizing packages with things installed in /usr instead
of /.
If you do not have separate /usr, you could just enjoy the ride. All
of this would be transparent to you. If you do have separate /usr, the
critical step will be bringing up an initramfs once you upgrade to
udev-176. Once that is done, you could also just enjoy the ride.
Thoughts?
William
pgpwrpWUR5VAh.pgp
Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 2012-01-03 at 14:35 -0500, Rich Freeman wrote: 2012/1/3 Olivier Crête tes...@gentoo.org: A couple years ago, Gentoo was the forward looking distribution, ready to try radical changes that break existing assumption, like our init scripts with dependencies or our early use of udev. These days, I see so much resistance to progress, it makes me sad. I think the key is to keep huge changes optional to start with. This one feels like it is being pushed upon us. I don't really have a big problem with moving to /usr and all that. However, I do have some concerns with the larger direction that everybody is taking with vertical integration (which this is just a part of). For example, if eventually you can't run gnome without systemd where does that leave bsd gentoo users? Gentoo is about choice, and various upstream efforts are moving in the direction of giving users only one choice - take it or leave it. How do you install KDE and Gnome on the same system when they eventually want different sysvinit implementations. Will the RedHat and Ubuntu of the future have no more in common than Tivo and Android do today? Well, don't worry, the KDE people don't have the will or the means to make their own init system.. And rumor is that Ubuntu may be switching to systemd in the near future too. With a Linux kernel, you already need some Linux specific things like udev, ifconfig/ip, etc. In the new world, you also have a Linux specific init system. The BSD people are free to do whatever they want, they can try to keep up with the Linux kernel, but good luck to them. Or they can stay in the 80s. My advice to them is to admit that Linux is so far ahead that they can't catch up and just join us. Honestly, we should not promote choice at the expense of quality, maintainability and reliability and these are the decisions that have been made by the udev/systemd/etc upstreams. All of the init systems of each Linux distribution has been doing the same thing in slightly incompatible ways, so everyone has to maintain separate init scripts, on each distro you have to remember where to set things like the hostname (/etc/conf.d/hostname, /etc/hostname, /etc/rc.d/hostname, /etc/system/hostname, etc/wtf), etc. One of the key goals of systemd is to reduce this confusion by standardising the boot process across all distributions. Vertical integration is the only way we can make things Just Work for the users, we tried to do abstraction layers (HAL for example), but it has been a failure. In the GNOME project, we're trying to make the Linux desktop awesome, and we plan to fix any part of the puzzle that would prevent us from achieving that goal. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote: On Mon, 2012-01-02 at 10:41 +0200, Eray Aslan wrote: RedHat made some bad design decisions on RPM (.rpmnew files anyone?) and udev. Udev was probably salvagable before systemd but noone has the motivation or the man-power to manage the huge delta that would result now. It would probably amount to forking udev. So people are following along even if they are unhappy. This is completely unrelated to RPMs. The same packages are moving towards a system where config files reside under /usr/lib with users overriding the defaults in /etc (/usr/lib/udev/rules.d/ and /etc/udev/rules.d). I doubt this would have come about if RPM had a sensible way of dealing with config files -if they had etc-update/dispatch-conf for example. -- Eray Aslan e...@gentoo.org signature.asc Description: Digital signature
Re: [gentoo-dev] Documentating advanced portage feaetures in Gentoo Handbook
On 3.1.2012 19.51, Sven Vermeulen wrote: [2] http://dev.gentoo.org/~swift/docs/previews/hb-portage-advanced.xml The discussion however is if it is okay to document these things there or not. Some of the features are considered to be too fragile to be broadly documented (at least in a beginners resource like the Gentoo Handbook) and might cause eventual bugs to be closed as RESO:WONTFIX because the user used such a feature. A quick read didn't seem like there would be something overly dangerous or support nightmare producing there. Regards, Petteri
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 03-01-2012 14:01:20 -0600, William Hubbs wrote:
On Tue, Jan 03, 2012 at 08:12:06PM +0100, Fabian Groffen wrote:
I think the best way to do this part of it is going to be to just follow
the upstream packages. When they release a new version that installs in
/usr, just allow that to happen. Eventually there will be very little in
/{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
/bin/sh.
What packages would that be? If you're thinking about coreutils, just
trim down the ebuild by not moving some of the tools to /bin. Our
ebuild makes it conform to FHS, not the coreutils buildsystem itself.
Yes, coreutils will have to be reworked in that case. I don't know what
the upstream build system does, but we will have to take a look at it.
Upstream build system has all binaries just installed in $(PREFIX)/bin,
like normal autoconf-based projects.
I'll have to go through on my system at
least and find all of the ebuilds that install things in
/{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
released; this will list all of the things we need to do to complete the
migration.
I would suggest not to do this. It's more interesting to know what udev
really requires to be in /usr/bin.
Basically I have these in my head:
* mask udev-176 in the tree.
* figure out and document how to make a simple initramfs with dracut.
* unmask udev 176 making sure to point users with a separate /usr
partition to how to make an initramfs (I could probably do this with
ewarns in the ebuild and maybe a news item before we go stable).
* stabilize a version of dracut.
* stabilize =udev-176 and kmod.
* Now start stabilizing packages with things installed in /usr instead
of /.
If the system can work with things being in /, why would we have to move
away from that? I don't like my systems breaking, and this is a likely
candidate to do so. E.g. also gcc-config needs changing for this. And
baselayout/openrc. How many locations for functions.sh are there
already in scripts now?
If you do not have separate /usr, you could just enjoy the ride. All
of this would be transparent to you. If you do have separate /usr, the
critical step will be bringing up an initramfs once you upgrade to
udev-176. Once that is done, you could also just enjoy the ride.
Thoughts?
Let's just first see how the rest of the world reacts to all of this.
We've waited serveral years with baselayout-1 - openrc/baselayout-2, so
I wouldn't mind doing some waiting here too. It doesn't look like
there's much going to change. I can't imagine bash devs dropping /bin
from bare default PATH (we control the default PATH), neither that glibc
folks drop /lib from the search path (although more likely since it's
more limited to Linux).
Perhaps, even start to experiment with this in an overlay (it's
relatively easy to start, just disable gen_usr_ldscript, fix bash to
pass --prefix=/usr and coreutils not to move bins) and try to see how
hard migration is with zlib moving around (shouldn't be too hard with
ELF, is a downright drama with Mach-O without portage's
preserve-libs).
But also, starting to experiment to see how easy it is to let things as
they are. udev might consider a world without /bin and /lib, but maybe
what's in there isn't much interesting to it anyway. Most stuff is
installed in /usr for a reason.
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] Documentating advanced portage feaetures in Gentoo Handbook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/03/2012 10:21 PM, Sven Vermeulen wrote: On Tue, Jan 03, 2012 at 09:57:04PM +, Roy Bamford wrote: Team, The Gentoo Handbook is about getting the base system installed. As such features such as per package CFLAGS have no place there. They are not within the scope of installing the base system. I disagree. The first part is about getting a base system. The rest of the handbook is to describe the Gentoo-specific administrative stuff. Wkr, Sven Vermeulen I agree. Advanced portage features can be in Gentoo Handbook provided it is clear that they should be not used without proper and complete understanding - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPA4PLAAoJEPqDWhW0r/LC5pgQAIPKKkn4dYaEz/R+BCdobPlP 1DBEdmB4IGFwPJfmDup6ubVcNuCwarJ9OXIx+kTuBtar48G7bbHljmhD53qWhFy/ 7PeYmrNuwy05SDH0n3xm69Bf0ycCVgX/SiF5diV5S9K+v+HCrvP6YVSvsmBYOvbt mlxvqnU8pMg/OnOfSUck+rOzvkbGTWOf8zkWL3YQ8r7hKeAkG/fZj0iTjDzAXlqf Ng5SEHiNsHzE96psVH1IuCH1gEz1La+WUpeXKg2FBj1IVOhl1DUCCYqWd5zd8HHX /K8vh8OVsgv0Vv6X78Ugus9wXdUoYzODdrbne1dlwOP/3DK0mYG87p04sJCKzO8j RC1TU85eM54gMSRdP58MG/wqwi3yFmiURrmlhhS9yz4c2vlJ1J9iLehxUjPTzt7G ZgR6Xbbkk/ksiq6x/62vptvx/8zXN8/iRG32G9ESAJBrTmcwm8b3jrZYewKRkw/G I82tu+ubWsdA+bOqD+Qcd810ybElMhGNb7SB/YMtoCGtGSha4DX/Tli/q8kw81zQ tnb2vCKRe22p4s0D6F5hP5EKOHvEGx2TQtTvmUf+4hrO5033yPp/KZXM1IL7qfj6 2Ic7KMK2dmQavPJGsEG5O94Fjoh8F3djnPq2DaRR8pH37Rxh2UI83ZGfjrsJqWPM nmaPjNOxBMKTBc3BqjTY =5eW+ -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, Jan 01, 2012 at 03:21:47PM -0500, Olivier Crête wrote: I use a separate /usr with LVM on all my systems. My root partition uses RAID1. And I never had the need for an initramfs of any kind. Also, there are some major hurdles to take when it comes to getting an initramfs working with SELinux. Most initramfs implementations I saw are not SELinux aware, so all changes they make to the system either result in failures when they try, or failures when the root-switch occurs. dracut fully supports SELinux (it's used in Fedora which has this SELinux horror on by default). Yes... but no. Fedora uses SELinux but using a policy where most domains run unconfined (meaning they're allowed to do almost anything) and mostly the network-facing services are confined. I just got dracut working on a SELinux system here (took me a few hours to compile a SELinux domain for dracut, because the application doesn't work with the standard privileges of an administrator) and it boots up (up to and including dracut: Switching root) until SELinux is activated. From that point onwards, it's dead since its using wrong labels and wrong context. It is SELinux-aware (it mounts the selinuxfs and such) but I think I'll need to edit the /usr/lib/dracut/* stuff to get it to boot up properly on a SELinux system that doesn't use unconfined domains... I'll try to get it working the next few days. Once (or when) it does, I'll submit the necessary patches to wherever is necessary. Wkr, Sven Vermeulen
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, Jan 03, 2012 at 10:22:15PM +0100, Fabian Groffen wrote:
I'll have to go through on my system at
least and find all of the ebuilds that install things in
/{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
released; this will list all of the things we need to do to complete the
migration.
I would suggest not to do this. It's more interesting to know what udev
really requires to be in /usr/bin.
The issues involve binaries in /{bin,sbin} that link to libraries in
/usr/lib as well as packages that install udev rules that run binaries.
Basically I have these in my head:
* mask udev-176 in the tree.
* figure out and document how to make a simple initramfs with dracut.
* unmask udev 176 making sure to point users with a separate /usr
partition to how to make an initramfs (I could probably do this with
ewarns in the ebuild and maybe a news item before we go stable).
* stabilize a version of dracut.
* stabilize =udev-176 and kmod.
The part of the process above is the part I am the most concerned about.
I think we need to get everyone who is using separate /usr switched over
to an initramfs with udev 176, and this needs to happen sooner than
later, without using things like wrapper scripts or ways to avoid the
initramfs. Those are just stop-gap options that will only work until
some package they are depending on migrates to /usr.
Once we get to this point in the process, I think we could take each
package that installs things in / individually and migrate it. But, I
think the part of the process listed above needs to happen sooner than
later.
What are your thoughts?
William
pgp7MYtFmonyV.pgp
Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 3 Jan 2012 17:09:18 -0600
William Hubbs willi...@gentoo.org wrote:
On Tue, Jan 03, 2012 at 10:22:15PM +0100, Fabian Groffen wrote:
I'll have to go through on my system at
least and find all of the ebuilds that install things in
/{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
released; this will list all of the things we need to do to
complete the migration.
I would suggest not to do this. It's more interesting to know what
udev really requires to be in /usr/bin.
The issues involve binaries in /{bin,sbin} that link to libraries in
/usr/lib as well as packages that install udev rules that run
binaries.
Basically I have these in my head:
* mask udev-176 in the tree.
* figure out and document how to make a simple initramfs with
dracut.
* unmask udev 176 making sure to point users with a separate /usr
partition to how to make an initramfs (I could probably do this
with ewarns in the ebuild and maybe a news item before we go
stable).
* stabilize a version of dracut.
* stabilize =udev-176 and kmod.
The part of the process above is the part I am the most concerned
about. I think we need to get everyone who is using separate /usr
switched over to an initramfs with udev 176, and this needs to happen
sooner than later, without using things like wrapper scripts or ways
to avoid the initramfs. Those are just stop-gap options that will
only work until some package they are depending on migrates to /usr.
Once we get to this point in the process, I think we could take each
package that installs things in / individually and migrate it. But, I
think the part of the process listed above needs to happen sooner than
later.
What are your thoughts?
I agree. Especially with the last part.
Thus, we need to:
1) fix and stabilize packages necessary to create an initramfs,
2) prepare really good instructions for creating one,
3) prepare a news item for users.
For the case of really simple initramfs mounting / and /usr only, I can
even create a small tool on klibc if anyone's interested.
--
Best regards,
Michał Górny
signature.asc
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] rfc: locations of binaries and separate /usr
William Hubbs schrieb:
On Tue, Jan 03, 2012 at 10:22:15PM +0100, Fabian Groffen wrote:
I'll have to go through on my system at
least and find all of the ebuilds that install things in
/{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
released; this will list all of the things we need to do to complete the
migration.
I would suggest not to do this. It's more interesting to know what udev
really requires to be in /usr/bin.
The issues involve binaries in /{bin,sbin} that link to libraries in
/usr/lib as well as packages that install udev rules that run binaries.
Basically I have these in my head:
* mask udev-176 in the tree.
* figure out and document how to make a simple initramfs with dracut.
* unmask udev 176 making sure to point users with a separate /usr
partition to how to make an initramfs (I could probably do this with
ewarns in the ebuild and maybe a news item before we go stable).
* stabilize a version of dracut.
* stabilize =udev-176 and kmod.
The part of the process above is the part I am the most concerned about.
I think we need to get everyone who is using separate /usr switched over
to an initramfs with udev 176, and this needs to happen sooner than
later, without using things like wrapper scripts or ways to avoid the
initramfs. Those are just stop-gap options that will only work until
some package they are depending on migrates to /usr.
Once we get to this point in the process, I think we could take each
package that installs things in / individually and migrate it. But, I
think the part of the process listed above needs to happen sooner than
later.
What are your thoughts?
William
If i did not miss something in this long thread, we are currently mostly
talking about udev needing /usr to be mounted when it starts. Systemd is
not our default init system and other packages are currently not
changing their default. Since udev is our default and that requires a
mounted /usr, we should show our users their options with a suggested
default:
1. minimal initramfs (default suggestion)
2. switching from udev to mdev (avoids required /usr of udev)
3. some wrapper script to mount /usr before udev starts
for 1: I use myself a self-created initramfs, which has worked fine for
many kernel releases, the only adjustment needed was back with kernel
2.6.27. With this in mind, some default minimal initramfs should be
doable without much maintaincence work.
for 2: from what i did read up to now, this option looks interesting for
those people, who dont want to use an initramfs or other mounting script
and dont use advanced features of udev, so especially server setups or
minimal desktop systems
For the idea of complete migration to /usr, i see no reason to go this
route in advance. Just keep with our default install locations and
follow upstream, if and where needed.
If a package switches to /usr and depending packages follow, fine, let
them do that and we can follow without much additional work.
There is no need to do such migration beforehand or changing our install
location in advance.
So in short:
1. Tell our users about the change in udev and show them their options
with a suggested default one.
2. for the rest, just calm down, follow upstreams and only change the
install location where needed. No need for mental pressure without an
actual pressure. ;-)
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Exorcising a d(a)emon from GNOME's past (aka EsounD Last Rites)
Hi folks, Today, I was shocked to find that the EsounD daemon is still in the tree and new ebuilds are actually still pulling it in under USE=esd! Proposal: package.mask media-sound/esound, use.mask USE=esd. Anything that still uses it should stop using it. Anything that /needs it/ should be purged from the tree with extreme prejudice[1]. I'll do the first two today, and the rest of the rituals necessary to complete the exorcism will take a month. Help in this regard is welcome since the job is rather straightforward. Thanks! 1. In exceptional cases, a dependency on pulseaudio will also suffice since pulseaudio emulates an esound socket while running with `module-protocol-esound-unix` loaded, which is the default. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] GCC 4.6 status
A bunch of users have been emailing me asking when 4.6 will be unmasked. I really want to get it out the door already but we have a (IMO) substantial blocker. A small number of users have reported that grub built with 4.6 fails to boot their systems. See the last half of bug #360513 for details. That report is actually two bugs, the first one had to do with .text.unlikely sections and was easy to reproduce without boot failures so I was able to accidentally fix it. The second I cannot reproduce and cannot get anyone brave and dumb enough to break their systems in the name of science for me. Several people have promised to go do some testing and have never been heard from again. Whether that is disappointing or ominous is left up to you. My current plan is to wait until someone smarter than me points out the obvious solution. Barring that, I'll be out of the country in a couple weeks and will unmask it when I get back. There should be several willing testers shortly after that. https://bugs.gentoo.org/360513 -- 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
