Gentoo Archives: gentoo-project

From: William Hubbs <williamh@g.o>
To: gentoo-project@l.g.o
Cc: council@g.o
Subject: Re: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC
Date: Sat, 05 May 2012 00:02:55
Message-Id: 20120504230637.GA2183@linux1
In Reply to: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC by "Jorge Manuel B. S. Vicetto"
On Wed, May 02, 2012 at 02:02:54AM +0000, Jorge Manuel B. S. Vicetto wrote:
> 3. Separate /usr partition vote of last meeting (20 minutes)
Hello Council Members, I was told that responding here is the best way to add information to the discussion you will have in the upcoming meeting about this vote, so that is why I am replying to this thread. Everyone seems to be focused on udev, but this issue goes a bit further than udev. I'm sure you have all read the document asserting why separate /usr without an initramfs is broken, but I'm going to reference it here just in case [1]. The following are concerns I have about us mandating that separate /usr without an initramfs is how we are going to do things: - We would have to introduce a new top-level directory, /share, as a counterpart to /usr/share. This would be for programs that currently read data from /usr/share but need to be made available in early boot. - Anything we might use at all during early boot must be stored in /, along with all of its dependencies. - Any program that hooks itself into udev must automatically be moved to / along with its dependencies. - The locale logic in linux always looks for information in /usr/share/locale. We would need to patch gettext to look in /share/locale as well. - If we decide a program needs to go into /, it, and all of its dependencies will need to be customized in the build process, and probably patched, to not refer to anything outside of /. - / will not be able to be kept small, which is a concern of some of our users. - Any patches we come up with to handle these issues most likely wouldn't be accepted into upstream, so we would be carrying them forever. If you use an initramfs to pre-mount /usr, all of these issues are moot and things just work (tm). Mike's sep-usr use flag option on busybox may do this, but see below. - Separate /usr without initramfs blocks the /usr merge. In my original request to have your vote reviewed, I pointed out the document which asserts that the /usr merge is a good thing and pointed out the thread in which we discussed it on -dev. The arguments supporting it are strong, and I haven't seen any technical argument against it that would not be addressed by using an initramfs with separate /usr. If you are using an initramfs, you will never know when the /usr merge happens, but if you are using something like Mike's option your system is not compatible with the merge. I also want to point out something out of the meeting log: <dberkholz> here's the thing <dberkholz> who's going to either "port" udev as necessary, or maintain an old version forever? [21:36] <dberkholz> we can't proclaim things like this from on high without a route forward <Chainsaw> I will keep an old version going until the end of time. <hwoarang> if udev is moving that way, we can't stay 'old' forever <dberkholz> what happens when kernel 3.6 no longer supports it? <Chainsaw> Then dev(tmp)fs will win. The new udev requires devtmpfs to function. devtmpfs creates the device nodes and udev manages everything else such as permissions, running external programs for certain events, loading kernel modules and creating extra symbolic links to device nodes. I do not see all of that functionality being moved into devtmpfs. So IMO the question still remains. If we take that route, what happens when the newer kernels do not support the older version of udev any longer? There is now a tracker bug open for the tasks which need to be done before newer udevs can be stabilized [2], and the documentation team has an initramfs guide [3]. My position is that we should use initramfs as our default method of supporting separate /usr, because if we don't, we will be hurting our distribution. We will require more and more things to be installed in / which will not be able to be kept small, we will create extra work for our maintainers who will have to maintain custom builds of their packages to support this, and we will block ourselves from doing the /usr merge. Thanks for your time. William [1] [2] [3]