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

[Duncan]

Michał Górny posted on Mon, 08 Feb 2016 13:46:06 +0100 as excerpted:

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

IMO that's the most important of the four issues.

While I switched to systemd some some time ago (I guess it's close to two 
years?), for those choosing openrc, given udev/systemd's upstream plans 
to go kdbus and hard-lockin to kdbus enabled kernels when that happens, 
plus the fact that they strongly discourage and don't really support 
separate udev already, it just doesn't make sense to me to default to 
systemd-udev on a non-systemd system.

But strong documentation is one of the things I appreciated about gentoo 
back in the day, it's one of the things I appreciate about systemd today, 
and it sounds like it's the biggest thing lacking in eudev, certainly so 
going forward from that kdbus thing coming to pass (*IF* it does, the 
jury, with Linus as the jury foreman, is still out on that one) in 
upstream systemd-udev and kernel and apps eventually being built assuming 
that, as at that point it's unlikely that eudev users will simply be able 
to use udev documentation any longer, as they can in general practice, 
today.

Of the first three issues, #1 (conflict-induced fork) and #2 (vanilla api) 
really don't apply so much to (e)udev as to systemd -- if you're a 
programmer targeting "vanilla", by definition, these days you're 
targeting systemd, and if you're *not* targeting systemd, by definition, 
you're no longer targeting vanilla and are thus dealing with all sorts of 
adaptations already, and both users and devs are already in a non-vanilla 
choice once they've chosen non-systemd.  Doing the same for eudev vs udev 
will add only trifling incrementally to that, like arguing whether taking 
a taxi or the city bus to your hotel will be faster, once you've chosen 
to go by cruise ship instead of airline.

#3 (eudev falling behind at times) could be a bit of a problem, but if it 
has been ahead at times as well, as already argued, without further 
information on specific instances, it's impossible to judge and thus is a 
wash.

Meanwhile, missing documentation affects all three of those as well as 
being its own, very critical, point.  If there's a reason to oppose the 
default switch, it'd be that, and that's where I believe some focus will 
need to be for eudev to be taken seriously, long-term, particularly given 
how well systemd is documented, making it easy for developers and users 
alike to simply settle on it as their standard, leaving support for other 
alternatives to those who might feel the need to develop and document 
them, and if they're not documented, well...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman