| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 08/02/16 07:46 AM, Michał Górny wrote: |
| 5 |
> On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer |
| 6 |
> <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 |
| 14 |
>> virtual/udev. For existing installs this has zero impact. For |
| 15 |
>> stage3 this would mean that eudev is pulled in instead of |
| 16 |
>> udev. |
| 17 |
>> |
| 18 |
>> The rationale behind this is: |
| 19 |
>> |
| 20 |
>> * eudev is an in-house fork, and there's more than a dozen |
| 21 |
>> distros already using it by default that are not us. Which is a |
| 22 |
>> little bit weird ... |
| 23 |
> |
| 24 |
> That's not an argument. I can also fork random system components. |
| 25 |
> Would you consider that a reason to replace the defaults with our |
| 26 |
> 'in-house' forks? |
| 27 |
> |
| 28 |
>> * Both udev and eudev have pretty much feature parity, so there |
| 29 |
>> won't be any user-visible changes |
| 30 |
>> |
| 31 |
>> * udev upstream strongly discourages standalone udev (without |
| 32 |
>> systemd) since at least 2012 |
| 33 |
>> |
| 34 |
>> (see for example: |
| 35 |
>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/0055 |
| 36 |
16.html |
| 37 |
>> |
| 38 |
>> |
| 39 |
https://lkml.org/lkml/2012/10/3/618 |
| 40 |
>> ) |
| 41 |
>> |
| 42 |
>> So it'd be (1) following upstreams recommendations and (2) |
| 43 |
>> dogfooding our own tools. I don't see any downsides to this :) |
| 44 |
> |
| 45 |
> I'm strongly against this, because: |
| 46 |
> |
| 47 |
> 1. It is a conflict-induced fork. As such, it will never be |
| 48 |
> merged upstream and it will never be supported upstream. In fact, |
| 49 |
> it is continually forces to follow upstream changes and adapt to |
| 50 |
> them. eudev is more likely to break because of the Gentoo |
| 51 |
> developer(s) working hard to merge upstream changes to their |
| 52 |
> incompatible code. |
| 53 |
|
| 54 |
Yes this is true -- however, this claim is based on sys-fs/udev |
| 55 |
actually being an upstream package and it really isn't -- it's a |
| 56 |
partial package of systemd that upstream really doesn't support as a |
| 57 |
separate package anyhow (hence the size and complexity of the ebuild |
| 58 |
to build it). |
| 59 |
|
| 60 |
> |
| 61 |
> 2. Many of Gentoo users are programmers who appreciate the |
| 62 |
> 'vanilla' API experience Gentoo often provides. Switching the |
| 63 |
> defaults to a fork that is known to intentionally diverge from |
| 64 |
> upstream goes against that principle. Programs written against |
| 65 |
> eudev may not work correctly with upstream udev. |
| 66 |
|
| 67 |
No. Eudev ensures compatibility with systemd-udev as a principle, |
| 68 |
we are not going to fork the API. Unless upstream decides to do |
| 69 |
something with udev that breaks it previous API in an incompatible |
| 70 |
way that cannot be reproduced without the rest of systemd, eudev |
| 71 |
will retain API compatibility with systemd-udev. Eudev would not be |
| 72 |
nearly as useful as it is, if it wasn't a drop-in replacement for |
| 73 |
upstream udevd and libudev. |
| 74 |
|
| 75 |
Besides, now that gudev is its own package there's really just |
| 76 |
libudev (rarely changes now), rules.d syntax (afaik hasnt changed |
| 77 |
since before the fork), and the support for the builtin's (which we |
| 78 |
keep up with) that we need to maintain. |
| 79 |
|
| 80 |
|
| 81 |
> 3. eudev has fallen behind systemd/udev more than once in the |
| 82 |
> past, and caused visible breakage to users this way. |
| 83 |
|
| 84 |
|
| 85 |
Similarly, in the last 6-12 months eudev's releases have been AHEAD |
| 86 |
of sys-fs/udev more than once, too. |
| 87 |
|
| 88 |
|
| 89 |
> 4. eudev is underdocumented, and the maintainer admits that 'he |
| 90 |
> sucks at documenting'. In fact, did anyone even bother to note |
| 91 |
> how far eudev diverges from upstream udev to this point? |
| 92 |
|
| 93 |
|
| 94 |
At this point, WITHOUT the patch applied by USE="rule-generator", |
| 95 |
divergence is fairly minimal -- the primary difference is that udev |
| 96 |
and libudev contain the internal functions that have been migrated |
| 97 |
upstream into the giant libsystemd-common. Most of the various |
| 98 |
improvement patches that we made in the early days have either been |
| 99 |
integrated upstream or have been dropped as they are no longer |
| 100 |
relevant. Blueness knows more on this, as I haven't done a thorough |
| 101 |
examination of upstream's code in quite a while. |
| 102 |
|
| 103 |
|
| 104 |
Oh, eudev also doesn't handle network link setup given that external |
| 105 |
tools already do this just fine. That's another difference, though |
| 106 |
not one that matters programmatically. That said, the network-link |
| 107 |
setup was added primarily to support systemd's use-case, and there's |
| 108 |
very little need or point in having it done by udevd on an rc-based |
| 109 |
system. |
| 110 |
|
| 111 |
|
| 112 |
|
| 113 |
-----BEGIN PGP SIGNATURE----- |
| 114 |
Version: GnuPG v2 |
| 115 |
|
| 116 |
iF4EAREIAAYFAla4u48ACgkQAJxUfCtlWe02JgD+KjY9zpYjh8JZf1gAu3QUahjN |
| 117 |
EqtAkPbXZLsELPBuAHgA/Aq2sHQIFg2iKYKow29HXIb43JKUbV96t37m9tUIBBm4 |
| 118 |
=trQk |
| 119 |
-----END PGP SIGNATURE----- |
Archives