On Tue, Apr 24, 2012 at 08:20:10PM -0400, Rich Freeman wrote:
> The fact that the ramifications are not just udev-related tends to
> point to the fact that this shouldn't simply be up to the udev team.
> These are big changes for Gentoo, and there is a great deal of
> controversy across the Linux world resulting from them (the
> Shuttleworth vs Pottering debate being the latest iteration of this).
> Everybody has to live with this stuff, which points to council
Everybody has to live with this stuff couldn't be more true. We are
talking about changes in the linux world that are coming from outside of
> On the other hand, somebody has to maintain all this code, so having a
> bunch of non-udev-maintainers telling them what to do is not a great
> thing either. Worst case you end up with a bunch of frustrated people
> giving up on it, which leaves us much worse off. If you are paying
> your staff you can tell them what to do, but with volunteers you need
> to be more "inspirational" in your leadership. If the udev team
> thinks this is the way the wind is blowing then either more people
> need to step up and help them maintain more configurability, or we
> need to just work with them to make the ride as smooth as we can. I
> don't think anybody wants to see needless end-user pain here in any
> case, and as far as I can tell the udev maintainers are quite willing
> to work with other projects (genkernel, dracut, docs, etc) as needed.
Like I said above, it isn't just the udev maintainers. We aren't talking
about changes to udev. we are talking about changes to the entire
> I think the best we can do is look for opportunities to give people
> choices when they're practical, and when people are willing to pitch
> in and maintain their side of the interfaces. You don't even have to
> be a Gentoo developer to do that - just look at OpenRC/etc - get an
> account on github, do good work, and ask some developer to commit your
I too am definitely a proponent of choice. However, I don't feel that
the choice of having /usr on a separate file system without using an
initramfs is a practical one to offer; especially with the /usr merge
coming down the pipe.
I didn't like making the change either. But, after some thought and
reading the arguments supporting it, I did, because I can see how it
will make things easier in the future.
Building an initramfs that works was simple on my system using genkernel; the
tracker for udev points to the bug that shows how to do it.
Once the documentation for setting up an initramfs is in place which
will be done before >=udev-182 is stabilized, all you will need to do is
set one up, then you can just enjoy the ride. We will not start the /usr
merge before this udev is stabilized.