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 |