From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EYDXS-0004Co-Jl for garchives@archives.gentoo.org; Sat, 05 Nov 2005 02:12:15 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jA52C1Wl010985; Sat, 5 Nov 2005 02:12:01 GMT Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jA52C05b005667 for ; Sat, 5 Nov 2005 02:12:01 GMT Received: from [192.168.1.15] (pcp04414054pcs.nrockv01.md.comcast.net[69.140.185.48]) by comcast.net (sccrmhc12) with ESMTP id <2005110502115901200mqjhbe>; Sat, 5 Nov 2005 02:11:59 +0000 Message-ID: <436C14E5.6010400@gentoo.org> Date: Fri, 04 Nov 2005 21:11:49 -0500 From: Kumba User-Agent: Thunderbird 1.4.1 (Windows/20051006) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-releng@gentoo.org Reply-to: gentoo-releng@lists.gentoo.org MIME-Version: 1.0 To: gentoo-releng@lists.gentoo.org Subject: Re: [gentoo-releng] Profile Reorganization References: <1130942011.26789.225.camel@cgianelloni.nuvox.net> In-Reply-To: <1130942011.26789.225.camel@cgianelloni.nuvox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 8fc0f4fe-45e1-4ff3-86d7-02ddbe59c34b X-Archives-Hash: e0033e49bee382b11f83873827054be8 Chris Gianelloni wrote: > Alright, I've had this idea for ways to reorganize the profiles for some > time now. I figured now would be as good a time as any to introduce it > here, since we probably do more profile work than anyone else. Once > we've got a decent idea hashed out, we can GLEP it and make the changes > in the tree. > > Basically, it is a reorganization of the profiles to make more sense. > > Profiles would consist of: > > $type/$kernel/$userland/$arch/($version) > > Now, type would be the main type of profile. To match with what we have > now, we would have "default" which is the default release profile, > "hardened" and "uclibc". We would keep the "base" profile, where the > globally-affecting things would remain. The kernel would be the kernel > in use. I believe that currently, we would have "linux", "darwin", and > "freebsd". The userland would be "gnu" or "bsd". Of course, arch is > pretty obvious. Everything below arch would be optional profiles. For > Release Engineering, this would be where we would put our versioned > release profiles, along with any other sub-profiles. > > All that this really accomplishes it a bit of cleanup of the profiles, > but also allows for greater support of more interesting profiles, such > as a hardened Linux profile with a BSD userland on Alpha. I would be more inclined to pester the portage folk to see about getting a more modular profile design (which I originally suggested when stacking support was being discussed) that allows plugging n' playing. i.e., Take the original idea I used for a variable in make.conf: EPROFILE="default:linux:mips:uclibc:selinux:ip30" Portage would then import the appropriate profile modules listed above and construct the profile that will be used on the system. In /usr/portage/profiles, we'd have modules defined that'd specify the base properties of that given profile, and probably other things, like identifying what level a profile is at, with 'default', 'linux', and 'uclibc' being your higher-level profiles since they follow the $type, $kernel, $userland design. Under those comes the $arch level ('mips') and then any $feature profiles, like 'hardened', 'selinux', or in mips' case, machines ('ip22', etc). Also included would be variables indicating what modules cannot be mixed together (i.e., 'linux' can't import a 'freebsd' or 'darwin' module). Doing this I think would allow for a much cleaner design of profiles than currently exists. As it stands, since we use both uclibc and glibc on mips, we'd have to re-replicate the entire mips profile subtrees under both default-linux/mips and uclibc/mips, and optionally under say, hardened/mips (once its features are tested). Using a more pluggable system will reduce this complexity and maintaince hassle significantly, I think. This pretty much entails a complete portage re-write I think...unsure on the specifics, but versus having to maintain a ton of profile trees, might be an idea worth discussing. --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond -- gentoo-releng@gentoo.org mailing list