On Wed, Feb 17, 2016 at 11:04 AM, Richard Yao <r...@gentoo.org> wrote:
> This is something that I think many of us who had systems broken by
> sys-fs/udev multiple times before sys-fs/eudev was an option thought was
> obvious.

About the only "system-breaking" change I'm aware of in udev over the
years was the change in default network interface names.  That was
preceded by news on how to avoid the change, or how to adapt to the

There certainly wasn't some change introduced without warning that
just broke systems in random ways.

> If a complete list of the breakages that lead to the creation of
> sys-fs/eudev were produced, I imagine that the list would have at least
> 3 to 5 items from the ~18 months before sys-fs/eudev with half of them
> were probably self inflicted by sys-fs/udev maintenance.

Anytime upstream changes something it is up to package maintainers to
evaluate the change and adapt to it as needed, especially for critical
packages like udev.  For the most part I think this is happening.
Whether it is the udev maintainers doing the QA or the eudev
maintainers doing the QA, somebody has to do the QA (and in Gentoo it
sounds like we do it twice, which is fine).

> I recall one incident involving whether udev should be in /sbin or
> /usr/sbin being resolved after 6 months of debate between then future
> eudev founders and sys-fs/udev maintainers only because the systemd
> developers told the sys-fs/udev maintainers it should be in /sbin like
> others had told them.

So, this sounds like a disagreement between the future eudev founders
and the udev maintainers in Gentoo.  It really has nothing to do with
udev itself.

And that is OK - we're allowed to have the same package maintained
under two different names by two sets of maintainers.  Obviously it
isn't ideal, and it would be better if everybody could agree.

> Another broke support for older kernels for no apparent benefit (and
> this sort of regression naturally enters sys-fs/udev):

That isn't really the same as "breaking Gentoo."  And as was pointed
out they did accept patches to provide support back.

I think it is a bit unfair to characterize the udev maintainers as
breaking things left and right.  They apparently differ with you in
how they prefer to set their defaults, and what their dependencies
are.  They apparently also accept patches when you provide them for
older kernels, which is what upstreams are supposed to do.

It really seems like the main reasons for eudev's existence right now
are (based on this thread):
1.  The eudev maintainers don't trust the udev maintainer's QA and
want to do their own layer of QA before introducing changes to the
2.  The eudev maintainers prefer a different default network interface
naming scheme (my understanding is that eudev can be configured to
behave as udev does by default, and vice-versa - for example, on the
box I'm typing this on my packets are going out over eth0 just fine on
3.  The eudev tarballs are smaller lacking the systemd components, and
the udev build system doesn't have to build the systemd components (I
don't think the same is true of udev but I could be wrong).

I'm not saying that eudev should go away, or that these concerns are
completely inappropriate.  If somebody wanted to fork their own kernel
stable series and carefully curate patches they could choose to do so
and package it in Gentoo, and give it different default configuration
options, and so on.


Reply via email to