Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-project
Navigation:
Lists: gentoo-project: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-project@g.o
From: William Hubbs <williamh@g.o>
Subject: Re: Council meeting: Tuesday 8th May 2012, 19:00 UTC
Date: Fri, 4 May 2012 18:06:37 -0500
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
Attachment:
pgpGeAIZMGt3F.pgp (PGP signature)
Replies:
Re: Council meeting: Tuesday 8th May 2012, 19:00 UTC
-- Mike Frysinger
References:
Council meeting: Tuesday 8th May 2012, 19:00 UTC
-- Jorge Manuel B. S. Vicetto
Navigation:
Lists: gentoo-project: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Council meeting: Tuesday 8th May 2012, 19:00 UTC
Next by thread:
Re: Council meeting: Tuesday 8th May 2012, 19:00 UTC
Previous by date:
Re: [gentoo-dev-announce] Returning Developer: Ben "yngwin" de Groot
Next by date:
Re: Council meeting: Tuesday 8th May 2012, 19:00 UTC


Updated Jul 05, 2012

Summary: Archive of the gentoo-project mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.