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 9965458973 for ; Tue, 9 Feb 2016 23:39:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8C78421C09C; Tue, 9 Feb 2016 23:39:02 +0000 (UTC) Received: from SMTP.Tech.Triadic.US (smtp.tech.triadic.us [98.102.61.98]) by pigeon.gentoo.org (Postfix) with ESMTP id 63D3F21C02C for ; Tue, 9 Feb 2016 23:39:01 +0000 (UTC) Received: from localhost (unknown [10.128.0.32]) by SMTP.Tech.Triadic.US (Postfix) with ESMTP id 5FBAA1040690 for ; Tue, 9 Feb 2016 18:26:17 -0500 (EST) X-Virus-Scanned: amavisd-new at Tech.Triadic.US Received: from SMTP.Tech.Triadic.US ([IPv6:::ffff:10.128.0.24]) by localhost (Milter1.Tech.Triadic.US [IPv6:::ffff:10.128.0.32]) (amavisd-new, port 10024) with LMTP id S07BgIVAR25V for ; Tue, 9 Feb 2016 18:26:15 -0500 (EST) Received: from [10.0.0.128] (cpe-24-29-169-98.cinci.res.rr.com [24.29.169.98]) by SMTP.Tech.Triadic.US (Postfix) with ESMTPSA id 9F9471040434 for ; Tue, 9 Feb 2016 18:26:15 -0500 (EST) Subject: Re: [gentoo-dev] Re: Changing order of default virtual/udev provider To: gentoo-dev@lists.gentoo.org References: <56B85B06.7020500@gentoo.org> <20160208134606.3a497035.mgorny@gentoo.org> <20160209192652.GO7732@vapier.lan> From: Alex McWhirter Message-ID: <56BA785C.6010205@triadic.us> Date: Tue, 9 Feb 2016 18:38:04 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 27f4c2ae-583e-43e6-a01e-72481dca3195 X-Archives-Hash: a9520709519b779c3c3d8c3182e6083c On 02/09/2016 05:39 PM, Duncan wrote: > I'd agree, except that the way we're running udev is strongly discouraged > and generally not supported by upstream, with a statement that it /will/ > break in the future, it's simply a matter of time. > > Which makes a big difference when supporting that same specific use-case > is the primary and arguably only reason the considered alternative exists. > > IOW, it's not about not liking upstream. It's about choosing a default > that supports our default use-case. > My point exactly. When this happens we either make something like eudev default or we have to make systemd default. I don't really care which as long as i still have the option to change it.