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
> involvement.

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
gentoo.

> 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
linux ecosystem.

> 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
> ebuilds.

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.

William