Re: [gentoo-releng] Profile Reorganization

[Kumba <kumba@gentoo.org>]

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