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] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
[2] http://bugs.gentoo.org/411627
[3] http://www.gentoo.org/doc/en/initramfs-guide.xml
|