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