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 3575B138247 for ; Sat, 7 Dec 2013 12:42:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7B678E0BA2; Sat, 7 Dec 2013 12:42:50 +0000 (UTC) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2623CE0B9B for ; Sat, 7 Dec 2013 12:42:48 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id c14so2021776vea.0 for ; Sat, 07 Dec 2013 04:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=0QgzDIp80IFt+TVB0kvLED5GxcgSRIeg3DR5cHO2rl0=; b=a0PFN63jzmR7z+9ElC747BaDGrMuBIuyft3QrgTnhNBIWdOl/cqXkQGEhl+2vqvqo4 FU4es3qTH8t499jM7g3i4nppi9WBg0StguHJvYzNinLUWA0bkaxkFbkgQPAvm+GA2yzo T31E9xsSiv8nHKGqP5HSXs+n8sxjIqdbqLvBBLj/Ho8zpwxYZtylbQmngDQ5ioYtoqHe c/g6F8jj/kZhvfC39g1PcQgID9zQAxnzlgpS2jGjriqCFhqy36ND0MKKPGzDUoVv+FyW Z2AmoBQbWbhgE7vZDlUEQi6TI4MMcXp4fsQgeO+w87FaYbU532gYKX+vVpHUBZHsYZgt XxNA== 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 X-Received: by 10.52.113.97 with SMTP id ix1mr4459156vdb.9.1386420168241; Sat, 07 Dec 2013 04:42:48 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.52.112.99 with HTTP; Sat, 7 Dec 2013 04:42:48 -0800 (PST) In-Reply-To: <52A2B788.3040409@gentoo.org> References: <20131201102015.GA1219@egeo> <20131202202845.GA8574@linux1> <529CF973.2020008@gentoo.org> <529CFAA1.7080608@gentoo.org> <20131203211130.GA31972@linux1> <52A2B788.3040409@gentoo.org> Date: Sat, 7 Dec 2013 07:42:48 -0500 X-Google-Sender-Auth: -FtmhA1UEztKi81MpRsuLpGMD5w Message-ID: Subject: Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 95f70cbe-a68a-4f11-ad66-f52e2bdb4e5f X-Archives-Hash: 5758115dee43457e5b3ab9572f5f91b4 On Sat, Dec 7, 2013 at 12:52 AM, Rick "Zero_Chaos" Farina wrote: > > 2.) having dhcpcd in this list will cause everything else to be cleaned > out that that is baaaad. imho, dhcpcd shouldn't be on this list at all > purely from a safety perspective. The stages will have dhcpcd so they > wouldn't end up with netifrc afaict. The problem is that dhcpcd can be used either as a network manager, or as a utility employed by a network manager. I'm not sure how use deps in virtuals work - if you could make the dependency on dhcpcd[network-manager] and not have portage try to get the user to change the config of dhcpcd if something else on the list is installed. The use flag wouldn't do anything, it would just be a message to portage that you intend to use dhcpcd as the network manager. But you could just as easily have the user do all of this manually - we don't have a kernel virtual to try to get the user to install a kernel. > Honestly, I'm not really sure why anyone would want to make stage3 less > functional than it already is but honestly net isn't something I'm ready > to give up just yet. It isn't about making the stage3 less functional, but about giving the user a choice. We don't stick a kernel in stage3, despite the fact that everybody needs one. We don't stick an MTA in the stage3 despite the fact that one of those is pretty hard to live without. Now that Gentoo apparently offers a wide selection of network managers, perhaps it makes sense to have the user pick which one they want to use. IMHO the purpose of @system and the stage3 is to solve the circular dependency problem inherent in bootstrapping. It really shouldn't contain anything beyond this. By all means have an @useful-utils set or some kind of profile that auto-installs a list of packages like openssh, vim, and so on. However, these are not required to bootstrap a system and I'm not sure why we should be forcing them into the @system set as a result. Another option would be to have things installed in the stage3 that are not part of the @system set, so that they would be depcleaned at a later date. I'm not a big fan of that, however, mainly because it could be a curve-ball for somebody to deal with after they think they've gotten everything working. I think users will have a better understanding of how their system is set up if they put things there than if things start out there but get yanked out from under them. Rich