Re: [gentoo-dev] Changing order of default virtual/udev provider

[Richard Yao]

On 02/17/2016 01:47 PM, Rich Freeman wrote:
> On Wed, Feb 17, 2016 at 11:04 AM, Richard Yao <ryao@g.o> 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
> change.
>
> 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.

That is just one thing that I remembered off the top of my head and
quite frankly, that situation was the most absurd system breakage
incident that ever occurred involving udev. The arguments by the
sys-fs/udev maintainers at the time were that upstream wanted it that
way when even the systemd developers did not agree with them. The matter
was only resolved after one of the sys-fs/udev maintainers decided to
ask the systemd developers what they actually thought after 6 months of
claiming their way was the upstream way and were told that they thought
the packaging was wrong. Everyone else had believed the sys-fs/udev
maintainers' statements that upstream actually thought such things, and
consequently, were adamant that the systemd maintainers had no idea what
they were doing.

There were multiple breakages caused by sys-fs/udev maintainance
following systemd assimilating udev based on the principle that upstream
wanted it that way. The outsourcing of responsibility for thought on
such things were one of the things that contributed to eudev's creation.
Another were absolute refusal by Kay Sievers at the time to fix
regressions when given patches. It was not "rewrite the patch this way".
It was along the lines of "we are not fixing that because we don't care
about people affected by this and fixing that would add 40 lines to the
codebase".

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

That is a new development.

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

There were multiple incidents where either the sys-fs/udev maintainers
or the systemd developers refused to listen to reason. Systems broke
because of it and there were no warnings.

> 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
> tree.
> 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
> systemd).
> 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.

That is a false equivalence because:

1. We have plenty of sys-kernel/*-sources packages, but Gentoo has no
true default because the user must pick a package.
2. Both mainline and the Gentoo kernel team do a decent job of not
breaking things and fix them promptely when things do break. There are
no drawn out arguments or debates about why things should be broken in
lieu of fixing things when them being broken has been recognized.