On 02/17/2016 01:47 PM, Rich Freeman wrote: > 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.
That is just one thing that I remembered off the top of my head and quite frankly, that situation was the most absurd system breakage incident that ever occurred involving udev. The arguments by the sys-fs/udev maintainers at the time were that upstream wanted it that way when even the systemd developers did not agree with them. The matter was only resolved after one of the sys-fs/udev maintainers decided to ask the systemd developers what they actually thought after 6 months of claiming their way was the upstream way and were told that they thought the packaging was wrong. Everyone else had believed the sys-fs/udev maintainers' statements that upstream actually thought such things, and consequently, were adamant that the systemd maintainers had no idea what they were doing. There were multiple breakages caused by sys-fs/udev maintainance following systemd assimilating udev based on the principle that upstream wanted it that way. The outsourcing of responsibility for thought on such things were one of the things that contributed to eudev's creation. Another were absolute refusal by Kay Sievers at the time to fix regressions when given patches. It was not "rewrite the patch this way". It was along the lines of "we are not fixing that because we don't care about people affected by this and fixing that would add 40 lines to the codebase". > 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. That is a new development. > 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. There were multiple incidents where either the sys-fs/udev maintainers or the systemd developers refused to listen to reason. Systems broke because of it and there were no warnings. > 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. That is a false equivalence because: 1. We have plenty of sys-kernel/*-sources packages, but Gentoo has no true default because the user must pick a package. 2. Both mainline and the Gentoo kernel team do a decent job of not breaking things and fix them promptely when things do break. There are no drawn out arguments or debates about why things should be broken in lieu of fixing things when them being broken has been recognized.
signature.asc
Description: OpenPGP digital signature
