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 451F6138247 for ; Fri, 6 Dec 2013 15:26:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C09E8E0B56; Fri, 6 Dec 2013 15:26:13 +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 D0964E0B40 for ; Fri, 6 Dec 2013 15:26:12 +0000 (UTC) Received: from [192.168.1.122] (bas1-ottawa09-2925288179.dsl.bell.ca [174.92.90.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id C450833F4B2 for ; Fri, 6 Dec 2013 15:26:11 +0000 (UTC) Message-ID: <52A1EC8F.3010505@gentoo.org> Date: Fri, 06 Dec 2013 10:26:07 -0500 From: Ian Stakenvicius 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: <20131202202845.GA8574@linux1> <529CF973.2020008@gentoo.org> <529CFAA1.7080608@gentoo.org> <20131203211130.GA31972@linux1> <529F5C6C.7060704@gentoo.org> <20131204212537.GA19609@linux1> <529FBE92.4000003@gentoo.org> <20131205015656.GA20136@linux1> In-Reply-To: <20131205015656.GA20136@linux1> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: bfb231f4-c8fb-4209-96aa-9a274fc0b1a9 X-Archives-Hash: 891e38833adfbb0d636822a953edda88 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/12/13 08:56 PM, William Hubbs wrote: > On Wed, Dec 04, 2013 at 07:17:45PM -0500, Mike Gilbert wrote: >> On Wed, Dec 4, 2013 at 6:45 PM, Patrick Lauer >> wrote: >>> On 12/05/2013 05:30 AM, Mike Gilbert wrote: >>>> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs >>>> wrote: >>>>> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen >>>>> wrote: >>>>>> seems like a virtual that wouldn't do anything useful >>>>>> except pull in random package(s) a la binary-distribution >>>>>> style >>>>> >>>>> What about the stages? Don't we need some form of net >>>>> support in stage 3? >>>>> >>>> >>>> That's debatable. For a typical install, the user has to >>>> install other basic stuff like a boot loader, kernel, etc. So >>>> having them also select a network config framework seems >>>> logical. >>>> >>>> Is there a use case for a stage3 in which installing netifrc >>>> by hand is impractical? >>>> >>> Well ... >>> >>> I remember filing a bug quite a while ago because we didn't >>> have a dhcp client included anymore. This made installs quite >>> annoying because before it was stage3, kernel, bootloader, go! >>> >>> And now it was go ... stop ... reboot ... install dhcp client >>> ... grremblwrrxrmkrxtlmrrrg .... reboot >>> >>> That extra step of whining was loud enough to have openrc fixed >>> to be able to use busybox udhcp, so that "out of the box" most >>> network worked. >>> >>> ... and now people are trying to do the same again. >>> >>> I would STRONGLY recommend having a working network setup >>> included in stage3, so that compared to now nothing changes. >>> >>> >> >> Yeah, after some further thought, I'm inclined to agree. > > I think we would be safe as long as we make sure to document in > the handbook that users must choose a network manager. We could > recommend netifrc by default for now until we can document how to > set up the others. > > Once all of this hits stable I want to work with releng to get > them to use standalone dhcpcd on the LiveCD. > > What do you think? If the stage3 could include a dhcp client and (ideally imo) netifrc, even though they aren't a part of @system, that would help prevent the "stuff missing, damnit, have to reboot back to livecd" cycle. Since it isn't part of @world we would still need the documentation and instructions for someone to explicitly choose a network provider, otherwise they'll be bitten with it disappearing via --depclean. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKh7I8ACgkQ2ugaI38ACPBeDgD9GV+Mk4mbHLRRzqAfXfqei5Ci JRLuN0I1e1nW08DT93oA/0FlNasD9KlGNCUwG6JrJhuEQs2H8Damau7KsWO2GibN =500q -----END PGP SIGNATURE-----