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
