On 15/02/16 02:16, Mike Frysinger wrote: > On 14 Feb 2016 15:56, Anthony G. Basile wrote: >> On 2/14/16 3:47 PM, Mike Frysinger wrote: >>> On 14 Feb 2016 15:42, Anthony G. Basile wrote: >>>> On 2/14/16 3:23 PM, Mike Frysinger wrote: >>>>> eudev: no one of any relevance outside of Gentoo runs it. >>>> that's not true, nor is it the central criticism, imo. >>> can you list the projects that utilize eudev ? the repo doesn't >>> that i can see. it is the central criticism imo when correct >>> interaction with other projects is key. people rely on rules being >>> parsed & run correctly, as well as information provided by udev >>> matching what they are running/testing everyday. >> until patrick brought up the list of distros, i was only aware of >> alpine which is a musl based distro. then puppy and slack came >> forward. they build their entire system using eudev as the libudev >> provider. if there were issues, they would bring forward bug reports >> like any other project. >> >> so when you say "people rely on rules being parsed ..." i don't know >> why those user bases are dismissed. > i'm not dismissing them per-se. i'm being practical here: i think you > can agree that the combined developer base of alpine/puppy/slack(ware?) > is significantly smaller as compared to the distros using udev. > -mike by "udev" do you mean systemd (as they are losely one-and-the-same) or the unsupported udev-severed-from-systemd ... Of course there is no comparison between Anthony's work on eudev and the systemd 'crowd' it's just a non-question.
I think people are confusing the fact that there IS no separate 'udev' .. it is the work of a gentoo maintainer to make it work without systemd. To this end, does it really matter that OpenRC users are reliant on a gentoo developer applying heavy patching of 'upstream' udev-for-systemd .. or another gentoo developer working on an alternative that's roughly API-compatible. The discussion is how you jump the inevitable shark, and perhaps by switching the default and having a bit of time ahead to deal with issues, is surely better than facing a large breakage ahead, when there remains an option to switch back to the current udev if there are problems with eudev. It also gives Anthony a chance to have a greater user-base to test and evaluate eudev so that improvements can be made in a timely fashion before udev-without-systemd becomes unavailable (for whatever set of reasons).
