On Thu, 2007-07-05 at 18:47 -0400, Mike Frysinger wrote:
> you proposing we rearchitect it all or just for testing purposes before going 
> live ?  i can see both ...

I am proposing rethinking all of it.  My current thoughts run something
like this:

arch/amd64
arch/ppc (not ppc/ppc64 or ppc/ppc32)
base
default/linux
default/freebsd
default/macos
kernel/darwin
kernel/linux
kernel/freebsd
release/2007.1
target/desktop
target/server
userland (these aren't all the same type of thing)
userland/32-bit
userland/64-bit
userland/multilib
userland/freebsd
userland/hardened
userland/linux (this could be glibc, instead)
userland/macos
userland/no-nptl (not sure we really need this, at all)
userland/nptl (this either)
userland/selinux
userland/uclibc

Of course, this is just my rough outline.  What you would end up with,
as a profile, is something like this:

default/linux/amd64/2007.1/desktop (not much different from now)

default inherits from base, then determines the parent path we take,
such as glibc over uclibc
linux is simple in this case since we're "default" meaning we'll have a
Linux kernel and glibc userland
amd64 is the architecture, of course... being "default" means it'll be
multilib automatically... this level should be the "highest" usable
level with the least amount of USE/etc enabled, as it should be only
what is required globally plus arch-specific
2007.1 is the release-specific profile and adds in the
changes/enhancements from that particular release
desktop is the target the profile is designed for, so it would have
additional USE enabled

I would also love to use package sets in some way in the profiles for
defining sets of packages that might be useful to the user without
forcing them into the "system" set for that profile.  Some examples of
what I mean would be adding things like dhcpcd and gentoolkit to the
default "desktop" profile without them being in system, so they can be
easily removed by users that don't want them.  This would, of course,
depend on the implementation used for package sets.

Taking the above example, to build a hardened server, you'd have
something like:

hardened/linux/amd64/2007.1/server (again not much different)

Of course, this is all just how I've been envisioning doing everything
and I'm sure other people have lots of ideas on their own.

I'm creating an overlay for these profiles while I work on them, so we
can easily get input on them and track the changes.  I'd like to get
input on this schema for the profiles before I commit anything and am
definitely interested in getting input from anyone with any profile
experience.  Using an overlay will allow us to make changes (to base,
for example) without disrupting the tree until we're ready.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation