| 1 |
On Thu, 2007-07-05 at 18:47 -0400, Mike Frysinger wrote: |
| 2 |
> you proposing we rearchitect it all or just for testing purposes before going |
| 3 |
> live ? i can see both ... |
| 4 |
|
| 5 |
I am proposing rethinking all of it. My current thoughts run something |
| 6 |
like this: |
| 7 |
|
| 8 |
arch/amd64 |
| 9 |
arch/ppc (not ppc/ppc64 or ppc/ppc32) |
| 10 |
base |
| 11 |
default/linux |
| 12 |
default/freebsd |
| 13 |
default/macos |
| 14 |
kernel/darwin |
| 15 |
kernel/linux |
| 16 |
kernel/freebsd |
| 17 |
release/2007.1 |
| 18 |
target/desktop |
| 19 |
target/server |
| 20 |
userland (these aren't all the same type of thing) |
| 21 |
userland/32-bit |
| 22 |
userland/64-bit |
| 23 |
userland/multilib |
| 24 |
userland/freebsd |
| 25 |
userland/hardened |
| 26 |
userland/linux (this could be glibc, instead) |
| 27 |
userland/macos |
| 28 |
userland/no-nptl (not sure we really need this, at all) |
| 29 |
userland/nptl (this either) |
| 30 |
userland/selinux |
| 31 |
userland/uclibc |
| 32 |
|
| 33 |
Of course, this is just my rough outline. What you would end up with, |
| 34 |
as a profile, is something like this: |
| 35 |
|
| 36 |
default/linux/amd64/2007.1/desktop (not much different from now) |
| 37 |
|
| 38 |
default inherits from base, then determines the parent path we take, |
| 39 |
such as glibc over uclibc |
| 40 |
linux is simple in this case since we're "default" meaning we'll have a |
| 41 |
Linux kernel and glibc userland |
| 42 |
amd64 is the architecture, of course... being "default" means it'll be |
| 43 |
multilib automatically... this level should be the "highest" usable |
| 44 |
level with the least amount of USE/etc enabled, as it should be only |
| 45 |
what is required globally plus arch-specific |
| 46 |
2007.1 is the release-specific profile and adds in the |
| 47 |
changes/enhancements from that particular release |
| 48 |
desktop is the target the profile is designed for, so it would have |
| 49 |
additional USE enabled |
| 50 |
|
| 51 |
I would also love to use package sets in some way in the profiles for |
| 52 |
defining sets of packages that might be useful to the user without |
| 53 |
forcing them into the "system" set for that profile. Some examples of |
| 54 |
what I mean would be adding things like dhcpcd and gentoolkit to the |
| 55 |
default "desktop" profile without them being in system, so they can be |
| 56 |
easily removed by users that don't want them. This would, of course, |
| 57 |
depend on the implementation used for package sets. |
| 58 |
|
| 59 |
Taking the above example, to build a hardened server, you'd have |
| 60 |
something like: |
| 61 |
|
| 62 |
hardened/linux/amd64/2007.1/server (again not much different) |
| 63 |
|
| 64 |
Of course, this is all just how I've been envisioning doing everything |
| 65 |
and I'm sure other people have lots of ideas on their own. |
| 66 |
|
| 67 |
I'm creating an overlay for these profiles while I work on them, so we |
| 68 |
can easily get input on them and track the changes. I'd like to get |
| 69 |
input on this schema for the profiles before I commit anything and am |
| 70 |
definitely interested in getting input from anyone with any profile |
| 71 |
experience. Using an overlay will allow us to make changes (to base, |
| 72 |
for example) without disrupting the tree until we're ready. |
| 73 |
|
| 74 |
-- |
| 75 |
Chris Gianelloni |
| 76 |
Release Engineering Strategic Lead |
| 77 |
Alpha/AMD64/x86 Architecture Teams |
| 78 |
Games Developer/Council Member/Foundation Trustee |
| 79 |
Gentoo Foundation |
Archives