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