On Wed, Feb 17, 2016 at 11:04 AM, Richard Yao <r...@gentoo.org> wrote: > > This is something that I think many of us who had systems broken by > sys-fs/udev multiple times before sys-fs/eudev was an option thought was > obvious.
About the only "system-breaking" change I'm aware of in udev over the years was the change in default network interface names. That was preceded by news on how to avoid the change, or how to adapt to the change. There certainly wasn't some change introduced without warning that just broke systems in random ways. > If a complete list of the breakages that lead to the creation of > sys-fs/eudev were produced, I imagine that the list would have at least > 3 to 5 items from the ~18 months before sys-fs/eudev with half of them > were probably self inflicted by sys-fs/udev maintenance. Anytime upstream changes something it is up to package maintainers to evaluate the change and adapt to it as needed, especially for critical packages like udev. For the most part I think this is happening. Whether it is the udev maintainers doing the QA or the eudev maintainers doing the QA, somebody has to do the QA (and in Gentoo it sounds like we do it twice, which is fine). > I recall one incident involving whether udev should be in /sbin or > /usr/sbin being resolved after 6 months of debate between then future > eudev founders and sys-fs/udev maintainers only because the systemd > developers told the sys-fs/udev maintainers it should be in /sbin like > others had told them. So, this sounds like a disagreement between the future eudev founders and the udev maintainers in Gentoo. It really has nothing to do with udev itself. And that is OK - we're allowed to have the same package maintained under two different names by two sets of maintainers. Obviously it isn't ideal, and it would be better if everybody could agree. > Another broke support for older kernels for no apparent benefit (and > this sort of regression naturally enters sys-fs/udev): That isn't really the same as "breaking Gentoo." And as was pointed out they did accept patches to provide support back. I think it is a bit unfair to characterize the udev maintainers as breaking things left and right. They apparently differ with you in how they prefer to set their defaults, and what their dependencies are. They apparently also accept patches when you provide them for older kernels, which is what upstreams are supposed to do. It really seems like the main reasons for eudev's existence right now are (based on this thread): 1. The eudev maintainers don't trust the udev maintainer's QA and want to do their own layer of QA before introducing changes to the tree. 2. The eudev maintainers prefer a different default network interface naming scheme (my understanding is that eudev can be configured to behave as udev does by default, and vice-versa - for example, on the box I'm typing this on my packets are going out over eth0 just fine on systemd). 3. The eudev tarballs are smaller lacking the systemd components, and the udev build system doesn't have to build the systemd components (I don't think the same is true of udev but I could be wrong). I'm not saying that eudev should go away, or that these concerns are completely inappropriate. If somebody wanted to fork their own kernel stable series and carefully curate patches they could choose to do so and package it in Gentoo, and give it different default configuration options, and so on. -- Rich
