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 026A61392EF for ; Wed, 2 Jul 2014 18:31:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DCE78E09FC; Wed, 2 Jul 2014 18:31:48 +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 DE6BAE09D9 for ; Wed, 2 Jul 2014 18:31:47 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id ABC5C33FF41 for ; Wed, 2 Jul 2014 18:31:46 +0000 (UTC) Message-ID: <53B4504C.9050508@gentoo.org> Date: Wed, 02 Jul 2014 14:32:44 -0400 From: "Anthony G. Basile" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.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] new profile layout with flavors and mix-ins References: <20140702154416.GA1151@linux1> <20140702195437.09c8efdb@pomiot.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 2083a781-d617-4ecc-9091-c69df8c1bc5e X-Archives-Hash: 8d172607c78072a7614331a3b06f2c71 On 07/02/14 14:10, Rich Freeman wrote: > On Wed, Jul 2, 2014 at 1:54 PM, Michał Górny wrote: >> I don't feel like we ought to vote on something like this without >> understanding most of the current profiles. And I'm afraid there are >> only few people who have any idea about the current profile >> structure... > No argument there. > > We may very well still end up with something hierarchical, but we can > at least limit that to the parts of the profile where it matters. > Maybe x86/BSD and amd64/Linux and amd64/Linux-hardened need to be > interdependent. However, that still gets rid of need to deal with > desktop environments, init systems, arguments over what belongs in > @system, and so on. We could have a blocker mechanism to keep people > from mixing systemd with BSD, or we could just let people shoot > themselves in the foot. > > Sounds like a good time to start reverse engineering the profiles... > > Rich > The way the profiles stack via the parent file makes them difficult to work with if they get to any significant depth. Here, for example, is the stacking for default/linux/mips/13.0/mipsel/multilib/n32 /usr/portage/profiles/base /usr/portage/profiles/default/linux */usr/portage/profiles/arch/base */usr/portage/profiles/arch/mips */usr/portage/profiles/default/linux/mips /usr/portage/profiles/releases /usr/portage/profiles/releases/13.0 /usr/portage/profiles/default/linux/mips/13.0 */usr/portage/profiles/arch/base */usr/portage/profiles/arch/mips */usr/portage/profiles/arch/mips/mipsel /usr/portage/profiles/default/linux/mips/13.0/mipsel */usr/portage/profiles/arch/base */usr/portage/profiles/arch/mips */usr/portage/profiles/arch/mips/mipsel /usr/portage/profiles/arch/mips/mipsel/mips64el /usr/portage/profiles/features/multilib /usr/portage/profiles/arch/mips/mipsel/mips64el/multilib /usr/portage/profiles/arch/mips/mipsel/mips64el/multilib/n32 /usr/portage/profiles/default/linux/mips/13.0/mipsel/multilib/n32 I put asterisks there to point out a pattern that gets pulled in repeatedly. Sometimes this isn't a problem but sometimes this leads to asserting something, then reverting it, then asserting it again. In the ancient selinux profiles (circa 2009) this meant you couldn't have a no-mutlilib amd64 system. Shallow profiles avoid this. Also "features" avoid this (the closest thing we have to mix-ins) provided they operate on a set of flags/packages orthogonal to the rest of the stack. You then have shallow base and you can add as many features as you like in, in any order, confident that one will not clobber stuff from another since each feature is well separated. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA