1 |
On Tue, 16 Feb 2016 21:54:31 -0500 |
2 |
Richard Yao <ryao@g.o> wrote: |
3 |
|
4 |
> On 02/08/2016 07:46 AM, Michał Górny wrote: |
5 |
> > On Mon, 8 Feb 2016 10:08:22 +0100 |
6 |
> > Patrick Lauer <patrick@g.o> wrote: |
7 |
> > |
8 |
> >> Ohey, |
9 |
> >> |
10 |
> >> I've opened a bug at: |
11 |
> >> https://bugs.gentoo.org/show_bug.cgi?id=573922 |
12 |
> >> |
13 |
> >> The idea here is to change the order of the providers of virtual/udev. |
14 |
> >> For existing installs this has zero impact. |
15 |
> >> For stage3 this would mean that eudev is pulled in instead of udev. |
16 |
> >> |
17 |
> >> The rationale behind this is: |
18 |
> >> |
19 |
> >> * eudev is an in-house fork, and there's more than a dozen distros |
20 |
> >> already using it by default that are not us. Which is a little bit weird ... |
21 |
> > |
22 |
> > That's not an argument. I can also fork random system components. Would |
23 |
> > you consider that a reason to replace the defaults with our 'in-house' |
24 |
> > forks? |
25 |
> > |
26 |
> >> * Both udev and eudev have pretty much feature parity, so there won't be |
27 |
> >> any user-visible changes |
28 |
> >> |
29 |
> >> * udev upstream strongly discourages standalone udev (without systemd) |
30 |
> >> since at least 2012 |
31 |
> >> |
32 |
> >> (see for example: |
33 |
> >> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html |
34 |
> >> https://lkml.org/lkml/2012/10/3/618 |
35 |
> >> ) |
36 |
> >> |
37 |
> >> So it'd be (1) following upstreams recommendations and (2) dogfooding |
38 |
> >> our own tools. I don't see any downsides to this :) |
39 |
> > |
40 |
> > I'm strongly against this, because: |
41 |
> > |
42 |
> > 1. It is a conflict-induced fork. As such, it will never be merged |
43 |
> > upstream and it will never be supported upstream. In fact, it is |
44 |
> > continually forces to follow upstream changes and adapt to them. eudev |
45 |
> > is more likely to break because of the Gentoo developer(s) working hard |
46 |
> > to merge upstream changes to their incompatible code. |
47 |
> |
48 |
> That was the entire point of the project. Upstream rejected any attempts |
49 |
> to do things that we actually needed and broke things claiming the |
50 |
> distributions were responsible for handling the breakage, so eudev was |
51 |
> started on the basis that we needed a project that would ensure that |
52 |
> changes in udev occur in a way that makes sense. |
53 |
|
54 |
What things? Things like 'let's try to spawn this script third time in |
55 |
case someone mounted something so that it happens to work this time'? |
56 |
Yes, that old behavior really made sense. |
57 |
|
58 |
> > 2. Many of Gentoo users are programmers who appreciate the 'vanilla' |
59 |
> > API experience Gentoo often provides. Switching the defaults to a fork |
60 |
> > that is known to intentionally diverge from upstream goes against that |
61 |
> > principle. Programs written against eudev may not work correctly with |
62 |
> > upstream udev. |
63 |
> |
64 |
> If upstream udev were stable, that would be one thing, but it |
65 |
> intentionally diverges from itself continuously. The only experience |
66 |
> that could be reliably provided with upstream udev is one of continual |
67 |
> breakage. |
68 |
|
69 |
This is FUD, without any proof. |
70 |
|
71 |
> |
72 |
> > 3. eudev has fallen behind systemd/udev more than once in the past, |
73 |
> > and caused visible breakage to users this way. |
74 |
> |
75 |
> When? |
76 |
|
77 |
Whenever we installed new systemd and udev versions, and needed to bump |
78 |
the dependency in virtual, and eudev maintainers were nowhere to be |
79 |
found. |
80 |
|
81 |
> Can we also consider all of the times udev broke the boot process |
82 |
> because upstream just didn't care about doing changes in a sane way and |
83 |
> the people interested in providing the upstream experience delivered on |
84 |
> that goal? |
85 |
|
86 |
Proof needed. |
87 |
|
88 |
> > 4. eudev is underdocumented, and the maintainer admits that 'he sucks |
89 |
> > at documenting'. In fact, did anyone even bother to note how far eudev |
90 |
> > diverges from upstream udev to this point? |
91 |
> |
92 |
> The FreeBSD developers were complaining about how poorly documented udev |
93 |
> was well before eudev existed. This is not a regression unless systemd's |
94 |
> innovations in replacing documented things with undocumented things made |
95 |
> them worse. |
96 |
|
97 |
So... replacing thing that has some docs with a thing that has no docs |
98 |
and links to docs of udev that aren't exact match for eudev is good? |
99 |
Good to know. |
100 |
|
101 |
-- |
102 |
Best regards, |
103 |
Michał Górny |
104 |
<http://dev.gentoo.org/~mgorny/> |