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

[Patrick Lauer]

On 02/09/2016 10:03 AM, Kent Fredric wrote:
> On 9 February 2016 at 18:27, Anthony G. Basile <blueness@g.o> wrote:
>> all the vitriolic attacks i get about eudev come from the gentoo
>> community.  outside of this community i get praise.
>
> In case my  earlier messages stating a desire to exercise much caution
> gave the wrong impression, I just want to state for the record I think
> its awesome eudev exists, and I think its awesome other distro's are
> using it.
>
> Just when it comes to "Change the defaults", I want to be certain
> about the path we're setting ourselves up for on this very important
> component, because here, a change of defaults paves a broader path for
> eudev to be a potential leading competition to systemd.
If, for any reason, eudev should be abandoned - we can just change the
virtual back. One-line change.
>
> Because if we do that, I feel we must be so sure of ourselves that
> eudev can be a profitable choice for at least a moderately long term,
> even in the event we get no more support from the systemd codebase.
>
> Having it in tree and having users who know what they're doing being
> able to choose their own risk factors and say "yeah, eudev is the
> right choice for what I'm doing" is one thing.
>
> But stating implicitly that "Hey, this is the default", this needs to
> be the *best* recommendation we can make based on all the other
> factors and other defaults Gentoo uses.
Given the options of {systemd, systemd-udevd standalone, eudev} -
Those that choose systemd are not in this discussion.
Systemd-udevd standalone is unsupported, with upstream suggesting that
they want to remove support for it.
Leaves eudev as the only 'sane' option, since we even have an upstream.

And it's the 'mainstream' choice.

And it wins the popular vote:
https://forums.gentoo.org/viewtopic-t-1038696-postdays-0-postorder-asc-highlight-eudev-start-0.html

>
> Because new users *will* be inclined to pick the default, and
> *existing* users of the *current* default are likely to see the
> default change, and reason "well, the default has changed, so the new
> default is the new best thing", and will be inclined to switch.
Existing installs won't have a visible change. Since a provider of
virtual/udev is installed nothing changes, even if we shuffle the
virtual providers around.
>
> And the worst thing we could have is a combination of bad defaults
> that leads new users to have a poor first experience because they used
> all the default recommendations, and their system made magic smoke
> instead of booting.
>
> In short, to change *this* default, it seems pertinent that we *know*
> that the change we're making *is* better and a more reliable long-term
> choice than the *current* default, and if there is *any reasonable
> doubt*, we should delay changing until that reasonable doubt is
> expunged.
>
Since eudev is a drop-in replacement that uses a good part of the
original udev codebase - if you notice any deviation it's either a bug
(which we should fix) or udev misbehaves (e.g. persistent network
naming, which is a wonderful way to make people with more than zero
network cards angry)

And again: It would only affect what gets installed if you do "emerge -C
udev eudev; emerge virtual/udev"
(and, as a positive side-effect, changes the udev implementation of
stage3, which again only affects the default on *new* installs)

I don't see any serious doubts, apart from "we're deviating from
upstream" - but that's exactly what I want to fix! Yes, we deviate
*now*, we should not do that. And there's reasonable doubt that we can
keep sys-fs/udev going.


I like it when people violently agree with me :)