Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[William Hubbs]

On Sun, Nov 18, 2012 at 10:48:33AM +0100, Pacho Ramos wrote:
> El dom, 18-11-2012 a las 11:13 +0200, Samuli Suominen escribió:
> > On 18/11/12 07:19, Greg KH wrote:
> > > On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote:
> > >> Having a builtin is a good idea, but the implementation as a mandatory
> > >> dependency on kmod is not. The plan is to reintroduce it as an optional
> > >> dependency, so that distributions (and Gentoo users) that do not want it
> > >> can avoid it. None of us want to force dependencies on others and there
> > >> is no need for this one.
> > >
> > > You do realize that you didn't really drop the dependency at all, right?
> >
> > Exactly what I had in mind. So far I see bunch of regressions (back to
> > bundling code :() in the "eudev" repository and more it deviates from
> > the orig. upstream the less attractive it's looking...
> >
> > What should be done, at most, is to cherry-pick and revert the things
> > that killed the sep. /usr support, put it behind an USE flag to the
> > current udev's ebuild, perhaps IUSE="+vanilla", and be done with it.
> >
> > - Samuli
> >
> >
>
> +1
>
> @eudev maintainers, Wouldn't that be possible?

Anything is possible.

The issue right now is the relationship between ryao and the udev team
(at least me).

I don't want to bore the list with the details, but ryao misunderstood
some action (or lack of action) on my part as ignoring him.

Samuli, myself and robbat2 are the udev team for gentoo. What I do not
know is if ryao spoke to the other team members, but what I do know is
that a private irc conversation months ago is fine, but, from my
perspective, it would have made sure that I didn't lose track of things
if bugs had been filed, and they were not, so that is the only reason I
lost track of his concerns.

I asked him several times about joining the udev team, but for whatever
reason, he feels that starting this fork was the best option, and he
has told me he can't stop it.

I'm with gregkh on the  separate /usr issue though. It isn't just udev
that has issues when /usr is split off. I think the myth that udev is
the only culprit came out of the April 2012 council meeting.

I'm pretty sure that what I'm about to say will be dismissed by the
supporters of separate /usr without an initramfs or without using the
sep-usr option we now have in our busybox ebuild, but in truth,
splitting / from /usr is broken another way that we have been ignoring
for a decade.

We have been getting around part of the issue by moving shared libraries
from /usr/lib* to /lib* and using gen_usr_ldscript to make sure the
linker knows what we have done with them.

The other breakage is any program that reads data from /usr/share does
not work right if / and /usr are split and that program starts in early boot.

I don't know what else would have to be fixed off the top of my head,
but  I can tell you that locales/nls are broken for early boot without
an initramfs if / and /usr are split.

Basically, if we want separate /usr without an initramfs and we want to
do it right, we have to create /share and start copying things from
/usr/share/* to /share/* and patching code to support reading both locations,
starting with gettext/NLS support.

So here is the question I'll pose. Is it worth all of that extra
work for us to support separate /usr correctly, or should we just tell
everyone to start using initramfs or, if they don't want to use
initramfs and they are just using plain filesystems, the
busybox[sep-usr] option once all of the tools are stable?

I used separate /usr for a long time here without an initramfs, but
after studying why this was broken, I switched over to an initramfs, and
have been running one for months, because that seems to be the cleanest
way forward.

There is one other issue right now,
and I don't know what util-linux is doing with it since our bug hasn't
been updated in some time [1].

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=410605