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"
1 On Wed, May 02, 2012 at 02:02:54AM +0000, Jorge Manuel B. S. Vicetto wrote:
2 > 3. Separate /usr partition vote of last meeting (20 minutes)
3
4 Hello Council Members,
5
6 I was told that responding here is the best way to add information to
7 the discussion you will have in the upcoming meeting about this vote, so
8 that is why I am replying to this thread.
9
10 Everyone seems to be focused on udev, but this issue goes a bit further
11 than udev. I'm sure you have all read the document asserting why
12 separate /usr without an initramfs is broken, but I'm going to reference
13 it here just in case [1].
14
15 The following are concerns I have about us mandating that separate /usr
16 without an initramfs is how we are going to do things:
17
18 - We would have to introduce a new top-level directory, /share, as a
19 counterpart to /usr/share. This would be for programs that currently
20 read data from /usr/share but need to be made available in early boot.
21
22 - Anything we might use at all during early boot must be stored in /,
23 along with all of its dependencies.
24
25 - Any program that hooks itself into udev must automatically be moved to
26 / along with its dependencies.
27
28 - The locale logic in linux always looks for information in
29 /usr/share/locale. We would need to patch gettext to look in
30 /share/locale as well.
31
32 - If we decide a program needs to go into /, it, and all of its
33 dependencies will need to be customized in the build process, and
34 probably patched, to not refer to anything outside of /.
35
36 - / will not be able to be kept small, which is a concern of some of our
37 users.
38
39 - Any patches we come up with to handle these issues most likely
40 wouldn't be accepted into upstream, so we would be carrying them
41 forever.
42
43 If you use an initramfs to pre-mount /usr, all of these issues are moot
44 and things just work (tm). Mike's sep-usr use flag option on busybox
45 may do this, but see below.
46
47 - Separate /usr without initramfs blocks the /usr merge.
48 In my original request to have your vote reviewed, I pointed out the
49 document which asserts that the /usr merge is a good thing and pointed
50 out the thread in which we discussed it on -dev. The arguments
51 supporting it are strong, and I haven't seen any technical argument
52 against it that would not be addressed by using an initramfs with
53 separate /usr. If you are using an initramfs, you will never know
54 when the /usr merge happens, but if you are using something like
55 Mike's option your system is not compatible with the merge.
56
57 I also want to point out something out of the meeting log:
58
59 <dberkholz> here's the thing
60 <dberkholz> who's going to either "port" udev as necessary, or maintain an old
61 version forever? [21:36]
62 <dberkholz> we can't proclaim things like this from on high
63 without a route
64 forward
65 <Chainsaw> I will keep an old version going until the
66 end of time.
67 <hwoarang> if udev is moving that way, we can't stay
68 'old' forever
69 <dberkholz> what happens when kernel 3.6 no longer
70 supports it?
71 <Chainsaw> Then dev(tmp)fs will win.
72
73 The new udev requires devtmpfs to function. devtmpfs creates the device
74 nodes and udev manages everything else such as permissions, running
75 external programs for certain events, loading kernel modules and
76 creating extra symbolic links to device nodes. I do not see all of that
77 functionality being moved into devtmpfs. So IMO the question still
78 remains. If we take that route, what happens when the newer kernels do
79 not support the older version of udev any longer?
80
81 There is now a tracker bug open for the tasks which need to be done
82 before newer udevs can be stabilized [2], and the documentation team has
83 an initramfs guide [3].
84
85 My position is that we should use initramfs as our default method of
86 supporting separate /usr, because if we don't, we will be hurting
87 our distribution. We will require more and more things to be installed
88 in / which will not be able to be kept small, we will create extra work
89 for our maintainers who will have to maintain custom builds of their
90 packages to support this, and we will block ourselves from doing the
91 /usr merge.
92
93 Thanks for your time.
94
95 William
96
97 [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
98 [2] http://bugs.gentoo.org/411627
99 [3] http://www.gentoo.org/doc/en/initramfs-guide.xml

Replies