-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/08/2016 04:46 AM, Michał Górny wrote: > On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer > <patr...@gentoo.org> wrote: > >> Ohey, >> >> I've opened a bug at: >> https://bugs.gentoo.org/show_bug.cgi?id=573922 >> >> The idea here is to change the order of the providers of >> virtual/udev. For existing installs this has zero impact. For >> stage3 this would mean that eudev is pulled in instead of udev. >> >> The rationale behind this is: >> >> * eudev is an in-house fork, and there's more than a dozen >> distros already using it by default that are not us. Which is a >> little bit weird ... > > That's not an argument. I can also fork random system components. > Would you consider that a reason to replace the defaults with our > 'in-house' forks? > >> * Both udev and eudev have pretty much feature parity, so there >> won't be any user-visible changes >> >> * udev upstream strongly discourages standalone udev (without >> systemd) since at least 2012 >> >> (see for example: >> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516 .html >> >> https://lkml.org/lkml/2012/10/3/618 >> ) >> >> So it'd be (1) following upstreams recommendations and (2) >> dogfooding our own tools. I don't see any downsides to this :) > > I'm strongly against this, because: > > 1. It is a conflict-induced fork. As such, it will never be merged > upstream and it will never be supported upstream. In fact, it is > continually forces to follow upstream changes and adapt to them. > eudev is more likely to break because of the Gentoo developer(s) > working hard to merge upstream changes to their incompatible code. > > 2. Many of Gentoo users are programmers who appreciate the > 'vanilla' API experience Gentoo often provides. Switching the > defaults to a fork that is known to intentionally diverge from > upstream goes against that principle. Programs written against > eudev may not work correctly with upstream udev. > > 3. eudev has fallen behind systemd/udev more than once in the > past, and caused visible breakage to users this way. > > 4. eudev is underdocumented, and the maintainer admits that 'he > sucks at documenting'. In fact, did anyone even bother to note how > far eudev diverges from upstream udev to this point? > May I ask which meaningful effects this has on systems that don't already run systemd? As it stands, upstream udev is one step (kdbus) away from full reliance on specific kernel and systemd versions. Which features of eudev have fallen behind enough to create breakage for users that use non-systemd init systems?
Given that eudev's purpose is to be init-agnostic, I would argue it's more in line with Gentoo's general goals and upstream is hostile enough to Gentoo's efforts to deliberately structure their software in a fashion that makes life harder for us. There's certainly no harm in considering them upstream and perhaps modeling eudev's updates/patches after theirs, but given upstream's goals to coerce everyone into using their init system, what workable long-term solution is there? A fork was really the only pragmatic approach here. This reminds me of the ffmpeg/libav issue. Thankfully since we've gotten past that, eudev/udev should be a simpler matter because we have prior experience to go off of. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWuJB9AAoJEAEkDpRQOeFwR74QAJ0a+uFI7E4Gmf6QGWe4t+lH hWrmflClGOcDOiP6imVTU+yrtL/f/aHAQUG4whfDRzc3zR4uBtpjhIKgPEdAsyFh aSvuOVjon6hEEvE2UA3SAOJErAD8bhGKDNArtLpLuWP9Ekjv7InL8EVFKfMbR/j2 tQMInjCip5BV9jf++9D/Nia46ilc/65eQz9k4jpqedVlZjGn/RIxpJXcKQAtdMPn JZ3w2n2przirn9hVQn7MZc4tBIPARnC1G/s7BC2pvGvbVwHTKZrkKhdS8kTWHJzk ME93G1HGRYJrSsHU0U0GSmbh+tC/1xAJFjcXG8+fi/dBjtYEyveMIQB66fVHkcvH pYuHeZ+uiuCvhRkOETYC6A92FFSQe41ofHf0JQx1OW0Br/mric74z5rg5BDA4bx7 22TrnN2M+cP2CC5jQi61rQ22Xh6jZ3x6EHuMN55iebuR7TuUBYBmT/qX1hvyubHl TPAKoxFnkhxcC9Ioe2lEpQxYdugQ0wxhUwQOvGsb/O1wU3WhX6ADWOavElhL7qHO 5vTiC6uq5ACz/qiwQ6QJU4ocSaJ1/qBTPFpp+WxeDryAEzmnjmiic/Uv0HGYWRaE 4GR0Kjv2AWuz4xEIbGKFadivUjTMVJHgW1CR2b8LId11UloEbjBBz48ar/fMS1xP ve4SvOASasKCk1Cc3uxV =LzE5 -----END PGP SIGNATURE-----
