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 203A61381DF for ; Wed, 17 Feb 2016 06:37:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CDF4921C00F; Wed, 17 Feb 2016 06:37:13 +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 A1077E080A for ; Wed, 17 Feb 2016 06:37:12 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id CD185340C53; Wed, 17 Feb 2016 06:36:40 +0000 (UTC) Date: Wed, 17 Feb 2016 07:37:04 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: Richard Yao Cc: gentoo-dev@lists.gentoo.org, Patrick Lauer Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider Message-ID: <20160217073704.49517441.mgorny@gentoo.org> In-Reply-To: <56C3E0E7.3000307@gentoo.org> References: <56B85B06.7020500@gentoo.org> <20160208134606.3a497035.mgorny@gentoo.org> <56C3E0E7.3000307@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/HWfPYWv8UJj6eJk5d_nnfxB"; protocol="application/pgp-signature" X-Archives-Salt: 35c40df4-cea0-49fb-af89-a126a4c4c541 X-Archives-Hash: ad1fba89317ede9fd91c97f2f5f6ae1f --Sig_/HWfPYWv8UJj6eJk5d_nnfxB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 16 Feb 2016 21:54:31 -0500 Richard Yao wrote: > 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 > >=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 > >=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. =20 >=20 > 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. What things? Things like 'let's try to spawn this script third time in case someone mounted something so that it happens to work this time'? Yes, that old behavior really made 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. =20 >=20 > 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. This is FUD, without any proof. >=20 > > 3. eudev has fallen behind systemd/udev more than once in the past, > > and caused visible breakage to users this way. =20 >=20 > When? Whenever we installed new systemd and udev versions, and needed to bump the dependency in virtual, and eudev maintainers were nowhere to be found. > 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? Proof needed. > > 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? =20 >=20 > 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. So... replacing thing that has some docs with a thing that has no docs and links to docs of udev that aren't exact match for eudev is good? Good to know. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/HWfPYWv8UJj6eJk5d_nnfxB Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWxBUQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOZz8QAKOesAhyi21/cGT0Krm3s0Zb xTb6Zh4L5PupXIX92gwAulSwkRBnoGVMSoG4Z57A4LBiVbRJkis6x748q1B/wPdx O/fN9LdHdUU9axdLXeXh3Q6fCaI91aB2TqrP4Dktsxo8M7uVKTrh1WpVGNYnZUT6 up8CHmr99HOKyZ6xa3quVb/GRNvvHw8/QlJgt889OR6/1bseJxkXdQmLJeo6/68n aN9mz6Q5/tkDdOhjazX//3yztK5LrCcwQeYUuqRcM9dbXG05GPu270jCzAL/nEk/ gj1Xt7jZBKE3Ts/ZaW8Gj9gaY6pDnMDxREE/1ngJzpTSBnDyCK92Lc4zxXKLtNST dHc2D9cTUODjsvjA+iE2gAlCxU9Ke5v4tazFNfqEAWuGDfHTgOJkgC/NqijHNPvy bsWbPkkAacLeRclvH2uVRDHAcSs6hGV61K2FsfKK53x8j6UjU/yPcScEPnG58p8X VByfNeRjUaFlNv6fRPd/vDBjtYW0DnfbMMo2SPMDQQxhBW4zcsmIcavZ4J60m2/g PtSqAnXjq7aBQdgITLXSAuZ7YnUmQrI720fdB7Fb48DBDvr0WvI3U8xD7RojQeFq 8sDvkccuv3V40bD6qXprdVFuQmTc5rZpcVmTelPXkIVGaGBV+E+k30fy2TcDvNgi UD9vzktrscBYzM/T5PoS =Rc4q -----END PGP SIGNATURE----- --Sig_/HWfPYWv8UJj6eJk5d_nnfxB--