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 545F813827E for ; Mon, 9 Dec 2013 23:27:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8266BE0B2D; Mon, 9 Dec 2013 23:27:51 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A2EA4E0B23 for ; Mon, 9 Dec 2013 23:27:50 +0000 (UTC) Received: from [192.168.1.101] (unknown [124.78.108.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: patrick) by smtp.gentoo.org (Postfix) with ESMTPSA id 6945D33F40C for ; Mon, 9 Dec 2013 23:27:49 +0000 (UTC) Message-ID: <52A65290.9060904@gentoo.org> Date: Tue, 10 Dec 2013 07:30:24 +0800 From: Patrick Lauer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up References: <20131201102015.GA1219@egeo> <20131202202845.GA8574@linux1> <529CF973.2020008@gentoo.org> <529CFAA1.7080608@gentoo.org> <20131203211130.GA31972@linux1> <52A2B788.3040409@gentoo.org> <20131208222552.GA22567@linux1> <52A5D89A.4080506@gentoo.org> In-Reply-To: <52A5D89A.4080506@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 4af7870a-8998-4fd1-91c4-8a95a617387c X-Archives-Hash: e8f4fcf57741476264cadc21075e41f2 On 12/09/2013 10:50 PM, Rick "Zero_Chaos" Farina wrote: > On 12/08/2013 05:25 PM, William Hubbs wrote: >> On Sat, Dec 07, 2013 at 12:52:08AM -0500, Rick "Zero_Chaos" Farina wrote: >>> 1.) If we are going to stuff this into @system then we probably want a >>> USE=nonet flag to allow users to not pull anything in if they really >>> don't want it. > >> We don't have to put this in @system at all. We could just have a >> virtual/network-manager, like we have virtual/cron, virtual/logger, >> virtual/mta, etc. None of these are installed by default; you have to >> choose one as part of your installation process. The more I read this >> thread, the more I agree with this approach; let the user make the >> choice as part of the installation process. > >>> Just as a side note, after reading the thread up through this point, I'm >>> terrified of the individuals who wish to remove networking support from >>> stage3 entirely. If anyone wants to push that idea then that needs to >>> be addressed by the council. Period. Such a major change is going to >>> cause a holy war, and myself and others will actively revert any change >>> which removes net from stage3 under the guise of "critical breakage" >>> unless there is council direction that says we are no longer including >>> net support in the stage3s. > >> I am in agreement with Rich and Peter. This isn't a matter of breaking >> the stages; it is a matter of us getting out of the way and letting the >> users pick the network stack they want. We do this for the kernel, boot >> loader, etc, so I don't understand why you feel we need council >> direction to make a similar change for the network manager. > > > I am softening a bit, but I'm really concerned that the stages all of a > sudden not having net is going to be an issue for people. Maybe I'm > mistaken, but it is hard for me to imagine that moving to a stage3 with > no net anything is an improvement. I suppose you can't download a > stage3 without net, so you should typically be able to just chroot in... And again I point at the precedent of having dhcp in stage3, then removing it and people getting quite frustrated with having no way to enable net properly. We had the same type of problem before, and it was fixed. Why are we trying to break it again, just so we fix it a week later when the complaints become loud enough? > I can honestly say most of the time when setup my arm systems I'm > unpacking the arm stage3 on an amd64 and then booting the arm device > with the base stage3 and fixing things from there. I suppose it is > possible to use qemu to install things, as long as I don't mind > pretending it's 1999 due to the slow emulation speeds... Yeah, I really > don't see an improvement here. It works fine for "I'm an amd64 user and > that's all I'll ever use" but when you start talking about smaller > arches it really starts to become a hassle imho. > > -Zero >