Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider
Date: Wed, 17 Feb 2016 18:47:52
Message-Id: CAGfcS_njmS43Tx2S6O6LRumHg784EAygRpOV85dc8eZ546FSTA@mail.gmail.com
In Reply to: Re: [gentoo-dev] Changing order of default virtual/udev provider by Richard Yao
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

Replies