From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A7A7D1381DF for ; Wed, 17 Feb 2016 02:55:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 329CE21C00D; Wed, 17 Feb 2016 02:54:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 119DFE077C for ; Wed, 17 Feb 2016 02:54:48 +0000 (UTC) Received: from [IPv6:2001:470:8840::2] (unknown [IPv6:2001:470:8840::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id B5363340BF6; Wed, 17 Feb 2016 02:54:47 +0000 (UTC) Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider To: gentoo-dev@lists.gentoo.org, Patrick Lauer References: <56B85B06.7020500@gentoo.org> <20160208134606.3a497035.mgorny@gentoo.org> From: Richard Yao X-Enigmail-Draft-Status: N1110 Message-ID: <56C3E0E7.3000307@gentoo.org> Date: Tue, 16 Feb 2016 21:54:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20160208134606.3a497035.mgorny@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3gnHrJ8eaR3PLcXLU7OqUP202iQBBe6qD" X-Archives-Salt: ec6c5c5c-7361-4d44-8d35-f42231f03d7a X-Archives-Hash: d83b3e27b4b592aedcbbca391b1f9dfd This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3gnHrJ8eaR3PLcXLU7OqUP202iQBBe6qD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/08/2016 07:46 AM, Micha=C5=82 G=C3=B3rny wrote: > On Mon, 8 Feb 2016 10:08:22 +0100 > Patrick Lauer wrote: >=20 >> Ohey, >> >> I've opened a bug at: >> https://bugs.gentoo.org/show_bug.cgi?id=3D573922 >> >> 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 wei= rd ... >=20 > 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? >=20 >> * 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 :) >=20 > I'm strongly against this, because: >=20 > 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. That was the entire point of the project. Upstream rejected any attempts to do things that we actually needed and broke things claiming the distributions were responsible for handling the breakage, so eudev was started on the basis that we needed a project that would ensure that changes in udev occur in a way that makes sense. > 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. If upstream udev were stable, that would be one thing, but it intentionally diverges from itself continuously. The only experience that could be reliably provided with upstream udev is one of continual breakage. > 3. eudev has fallen behind systemd/udev more than once in the past, > and caused visible breakage to users this way. When? Can we also consider all of the times udev broke the boot process because upstream just didn't care about doing changes in a sane way and the people interested in providing the upstream experience delivered on that goal? > 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? The FreeBSD developers were complaining about how poorly documented udev was well before eudev existed. This is not a regression unless systemd's innovations in replacing documented things with undocumented things made them worse. --3gnHrJ8eaR3PLcXLU7OqUP202iQBBe6qD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWw+DvAAoJECDuEZm+6ExkkJ8P/2L+Qpr2eJnERSmloAq9T1C2 KIPDjif7ktMr66BRDXMb4+JOa4orQnneBIdqr1537nIdE6M34/JnMRIEbGRhn7Q9 wN6TlpHE6K2gIFmiY2wf7onOcw6xliliYZ4lEt/i4gdg+UpWjy53eSV30oB8hLRo 89QelqceCVH5337ixNaG+dycVC7lpUDgROJa6DskYlbRAUjr2lnqJjYphmaIExG1 VCSTpAuhYFwItXoP8jSfI48v/WJc1u0WLhg8KLw2b5G7Bm2eocdboMm+1PI1Uy/C A/u1DivAQkryhQoab3nDIWFWzWMOe5LU7reAkg0UElmq31q226FOtntxFwApGfnv f8QoueNUc0gX75hrJ/DQD6O0feKyjGwANS+5U/B6Q+xgxFHu2qKi6A3SE4sxp8Ac e8EGk6MWdBvKwMIe3Z4vESAf1zsWoWVkKQJlKzqWuIp2KqKdvFZZZDKHAigZELOv jvYjtmQSt3Xab/saPyGhRapKJ604TA6QRcQyQ8vBWBjUET0Dzb8zRGXlqkIDzwa4 RjXtVaO4mVSSRySZLEfCYBGzRiP9SxuIXvwgTRiz39dZxUBXfd7fBHEIs76UCA3O pM/G81B1bezQzPRRI4/XNmwp2VP5Y1DkEbI6iqkH3zagduN1BvqbplRtCeT0MCzM IQESFIwPECs8y3nVmrtG =TICU -----END PGP SIGNATURE----- --3gnHrJ8eaR3PLcXLU7OqUP202iQBBe6qD--