| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 02/08/2016 04: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 udev. |
| 16 |
>> |
| 17 |
>> The rationale behind this is: |
| 18 |
>> |
| 19 |
>> * eudev is an in-house fork, and there's more than a dozen |
| 20 |
>> distros already using it by default that are not us. Which is a |
| 21 |
>> little bit weird ... |
| 22 |
> |
| 23 |
> That's not an argument. I can also fork random system components. |
| 24 |
> Would you consider that a reason to replace the defaults with our |
| 25 |
> 'in-house' forks? |
| 26 |
> |
| 27 |
>> * Both udev and eudev have pretty much feature parity, so there |
| 28 |
>> won't be any user-visible changes |
| 29 |
>> |
| 30 |
>> * udev upstream strongly discourages standalone udev (without |
| 31 |
>> systemd) since at least 2012 |
| 32 |
>> |
| 33 |
>> (see for example: |
| 34 |
>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516 |
| 35 |
.html |
| 36 |
>> |
| 37 |
>> |
| 38 |
https://lkml.org/lkml/2012/10/3/618 |
| 39 |
>> ) |
| 40 |
>> |
| 41 |
>> So it'd be (1) following upstreams recommendations and (2) |
| 42 |
>> dogfooding our own tools. I don't see any downsides to this :) |
| 43 |
> |
| 44 |
> I'm strongly against this, because: |
| 45 |
> |
| 46 |
> 1. It is a conflict-induced fork. As such, it will never be merged |
| 47 |
> upstream and it will never be supported upstream. In fact, it is |
| 48 |
> continually forces to follow upstream changes and adapt to them. |
| 49 |
> eudev is more likely to break because of the Gentoo developer(s) |
| 50 |
> working hard to merge upstream changes to their incompatible code. |
| 51 |
> |
| 52 |
> 2. Many of Gentoo users are programmers who appreciate the |
| 53 |
> 'vanilla' API experience Gentoo often provides. Switching the |
| 54 |
> defaults to a fork that is known to intentionally diverge from |
| 55 |
> upstream goes against that principle. Programs written against |
| 56 |
> eudev may not work correctly with upstream udev. |
| 57 |
> |
| 58 |
> 3. eudev has fallen behind systemd/udev more than once in the |
| 59 |
> past, and caused visible breakage to users this way. |
| 60 |
> |
| 61 |
> 4. eudev is underdocumented, and the maintainer admits that 'he |
| 62 |
> sucks at documenting'. In fact, did anyone even bother to note how |
| 63 |
> far eudev diverges from upstream udev to this point? |
| 64 |
> |
| 65 |
May I ask which meaningful effects this has on systems that don't |
| 66 |
already run systemd? As it stands, upstream udev is one step (kdbus) |
| 67 |
away from full reliance on specific kernel and systemd versions. Which |
| 68 |
features of eudev have fallen behind enough to create breakage for |
| 69 |
users that use non-systemd init systems? |
| 70 |
|
| 71 |
Given that eudev's purpose is to be init-agnostic, I would argue it's |
| 72 |
more in line with Gentoo's general goals and upstream is hostile |
| 73 |
enough to Gentoo's efforts to deliberately structure their software in |
| 74 |
a fashion that makes life harder for us. There's certainly no harm in |
| 75 |
considering them upstream and perhaps modeling eudev's updates/patches |
| 76 |
after theirs, but given upstream's goals to coerce everyone into using |
| 77 |
their init system, what workable long-term solution is there? A fork |
| 78 |
was really the only pragmatic approach here. |
| 79 |
|
| 80 |
This reminds me of the ffmpeg/libav issue. Thankfully since we've |
| 81 |
gotten past that, eudev/udev should be a simpler matter because we |
| 82 |
have prior experience to go off of. |
| 83 |
|
| 84 |
- -- |
| 85 |
Daniel Campbell - Gentoo Developer |
| 86 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
| 87 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |
| 88 |
-----BEGIN PGP SIGNATURE----- |
| 89 |
Version: GnuPG v2 |
| 90 |
|
| 91 |
iQIcBAEBCAAGBQJWuJB9AAoJEAEkDpRQOeFwR74QAJ0a+uFI7E4Gmf6QGWe4t+lH |
| 92 |
hWrmflClGOcDOiP6imVTU+yrtL/f/aHAQUG4whfDRzc3zR4uBtpjhIKgPEdAsyFh |
| 93 |
aSvuOVjon6hEEvE2UA3SAOJErAD8bhGKDNArtLpLuWP9Ekjv7InL8EVFKfMbR/j2 |
| 94 |
tQMInjCip5BV9jf++9D/Nia46ilc/65eQz9k4jpqedVlZjGn/RIxpJXcKQAtdMPn |
| 95 |
JZ3w2n2przirn9hVQn7MZc4tBIPARnC1G/s7BC2pvGvbVwHTKZrkKhdS8kTWHJzk |
| 96 |
ME93G1HGRYJrSsHU0U0GSmbh+tC/1xAJFjcXG8+fi/dBjtYEyveMIQB66fVHkcvH |
| 97 |
pYuHeZ+uiuCvhRkOETYC6A92FFSQe41ofHf0JQx1OW0Br/mric74z5rg5BDA4bx7 |
| 98 |
22TrnN2M+cP2CC5jQi61rQ22Xh6jZ3x6EHuMN55iebuR7TuUBYBmT/qX1hvyubHl |
| 99 |
TPAKoxFnkhxcC9Ioe2lEpQxYdugQ0wxhUwQOvGsb/O1wU3WhX6ADWOavElhL7qHO |
| 100 |
5vTiC6uq5ACz/qiwQ6QJU4ocSaJ1/qBTPFpp+WxeDryAEzmnjmiic/Uv0HGYWRaE |
| 101 |
4GR0Kjv2AWuz4xEIbGKFadivUjTMVJHgW1CR2b8LId11UloEbjBBz48ar/fMS1xP |
| 102 |
ve4SvOASasKCk1Cc3uxV |
| 103 |
=LzE5 |
| 104 |
-----END PGP SIGNATURE----- |
Archives