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 |