Gentoo Archives: gentoo-project

From: William Hubbs <williamh@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08
Date: Wed, 25 Apr 2012 06:04:15
Message-Id: 20120425033445.GA7542@linux1
In Reply to: Re: [gentoo-project] Call for agenda items -- Council meeting 2012-05-08 by Rich Freeman
1 On Tue, Apr 24, 2012 at 08:20:10PM -0400, Rich Freeman wrote:
2 > The fact that the ramifications are not just udev-related tends to
3 > point to the fact that this shouldn't simply be up to the udev team.
4 > These are big changes for Gentoo, and there is a great deal of
5 > controversy across the Linux world resulting from them (the
6 > Shuttleworth vs Pottering debate being the latest iteration of this).
7 > Everybody has to live with this stuff, which points to council
8 > involvement.
9
10 Everybody has to live with this stuff couldn't be more true. We are
11 talking about changes in the linux world that are coming from outside of
12 gentoo.
13
14 > On the other hand, somebody has to maintain all this code, so having a
15 > bunch of non-udev-maintainers telling them what to do is not a great
16 > thing either. Worst case you end up with a bunch of frustrated people
17 > giving up on it, which leaves us much worse off. If you are paying
18 > your staff you can tell them what to do, but with volunteers you need
19 > to be more "inspirational" in your leadership. If the udev team
20 > thinks this is the way the wind is blowing then either more people
21 > need to step up and help them maintain more configurability, or we
22 > need to just work with them to make the ride as smooth as we can. I
23 > don't think anybody wants to see needless end-user pain here in any
24 > case, and as far as I can tell the udev maintainers are quite willing
25 > to work with other projects (genkernel, dracut, docs, etc) as needed.
26
27 Like I said above, it isn't just the udev maintainers. We aren't talking
28 about changes to udev. we are talking about changes to the entire
29 linux ecosystem.
30
31 > I think the best we can do is look for opportunities to give people
32 > choices when they're practical, and when people are willing to pitch
33 > in and maintain their side of the interfaces. You don't even have to
34 > be a Gentoo developer to do that - just look at OpenRC/etc - get an
35 > account on github, do good work, and ask some developer to commit your
36 > ebuilds.
37
38 I too am definitely a proponent of choice. However, I don't feel that
39 the choice of having /usr on a separate file system without using an
40 initramfs is a practical one to offer; especially with the /usr merge
41 coming down the pipe.
42
43 I didn't like making the change either. But, after some thought and
44 reading the arguments supporting it, I did, because I can see how it
45 will make things easier in the future.
46
47 Building an initramfs that works was simple on my system using genkernel; the
48 tracker for udev points to the bug that shows how to do it.
49
50 Once the documentation for setting up an initramfs is in place which
51 will be done before >=udev-182 is stabilized, all you will need to do is
52 set one up, then you can just enjoy the ride. We will not start the /usr
53 merge before this udev is stabilized.
54
55 William

Replies