On 9 February 2016 at 01:46, Michał Górny <mgo...@gentoo.org> 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
