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

[Kent Fredric]

On 9 February 2016 at 01:46, Michał Górny <mgorny@g.o> wrote:
> 1. It is a conflict-induced fork. As such, it will never be merged
> upstream and it will never be supported upstream. In fact, it is
> continually forces to follow upstream changes and adapt to them. eudev
> is more likely to break because of the Gentoo developer(s) working hard
> to merge upstream changes to their incompatible code.
>
> 2. Many of Gentoo users are programmers who appreciate the 'vanilla'
> API experience Gentoo often provides. Switching the defaults to a fork
> that is known to intentionally diverge from upstream goes against that
> principle. Programs written against eudev may not work correctly with
> upstream udev.
>
> 3. eudev has fallen behind systemd/udev more than once in the past,
> and caused visible breakage to users this way.
>
> 4. eudev is underdocumented, and the maintainer admits that 'he sucks
> at documenting'. In fact, did anyone even bother to note how far eudev
> diverges from upstream udev to this point?


These problems can be resolved, but the resources involved with
resolving them are not trivial.

For instance, all it would take to change #1 and #2 would be for
`eudev` to become an external project, not an implied child of Gentoo,
and for our tools to consider it as such.

That is, instead of users being encouraged to see eudev as "Gentoos
Udev Fork", they'd have to see it as a stand-alone fork of udev with
the goals of retaining the axioms and values of Unix systems and
simplicity.

Then it would be resorted to the question of "Which external competing
udev implementation makes sense for our default value in conjunction
with our other default value of rc systems: OpenRC"

#3 and #4 are the more important criticisms IME, and we need eudev to
be the responsibility of more than one person and have a
survival,reliability and progression strategy that will continue in
the event upstream drop udev entirely to the point that Gentoo cannot
simply port their changes anymore.

Because if *that* happens, the fragmentation will become a much bigger
problem, and systemd getting bug fixes and updates while eudev gets no
love is not really much of a long term solution.

In short, for eudev to be a viable long term solution, we might need
to have a guarantee of investing a lot more resources in the project
than we presently can afford.

And until we have some kind of tacit assurance that we can do this,
making it the default might not be the best choice.

That said, if the upstream fragmentation is going to go in the "no
backports and udev goes away" direction, users currently taking the
"udev" choice are in for some bumpy waters eventually anyway.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL