| 1 |
Chris Gianelloni wrote: |
| 2 |
> Alright, I've had this idea for ways to reorganize the profiles for some |
| 3 |
> time now. I figured now would be as good a time as any to introduce it |
| 4 |
> here, since we probably do more profile work than anyone else. Once |
| 5 |
> we've got a decent idea hashed out, we can GLEP it and make the changes |
| 6 |
> in the tree. |
| 7 |
> |
| 8 |
> Basically, it is a reorganization of the profiles to make more sense. |
| 9 |
> |
| 10 |
> Profiles would consist of: |
| 11 |
> |
| 12 |
> $type/$kernel/$userland/$arch/($version) |
| 13 |
> |
| 14 |
> Now, type would be the main type of profile. To match with what we have |
| 15 |
> now, we would have "default" which is the default release profile, |
| 16 |
> "hardened" and "uclibc". We would keep the "base" profile, where the |
| 17 |
> globally-affecting things would remain. The kernel would be the kernel |
| 18 |
> in use. I believe that currently, we would have "linux", "darwin", and |
| 19 |
> "freebsd". The userland would be "gnu" or "bsd". Of course, arch is |
| 20 |
> pretty obvious. Everything below arch would be optional profiles. For |
| 21 |
> Release Engineering, this would be where we would put our versioned |
| 22 |
> release profiles, along with any other sub-profiles. |
| 23 |
> |
| 24 |
> All that this really accomplishes it a bit of cleanup of the profiles, |
| 25 |
> but also allows for greater support of more interesting profiles, such |
| 26 |
> as a hardened Linux profile with a BSD userland on Alpha. |
| 27 |
|
| 28 |
I would be more inclined to pester the portage folk to see about getting a more |
| 29 |
modular profile design (which I originally suggested when stacking support was |
| 30 |
being discussed) that allows plugging n' playing. |
| 31 |
|
| 32 |
i.e., Take the original idea I used for a variable in make.conf: |
| 33 |
|
| 34 |
EPROFILE="default:linux:mips:uclibc:selinux:ip30" |
| 35 |
|
| 36 |
Portage would then import the appropriate profile modules listed above and |
| 37 |
construct the profile that will be used on the system. |
| 38 |
|
| 39 |
In /usr/portage/profiles, we'd have modules defined that'd specify the base |
| 40 |
properties of that given profile, and probably other things, like identifying |
| 41 |
what level a profile is at, with 'default', 'linux', and 'uclibc' being your |
| 42 |
higher-level profiles since they follow the $type, $kernel, $userland design. |
| 43 |
Under those comes the $arch level ('mips') and then any $feature profiles, like |
| 44 |
'hardened', 'selinux', or in mips' case, machines ('ip22', etc). Also included |
| 45 |
would be variables indicating what modules cannot be mixed together (i.e., |
| 46 |
'linux' can't import a 'freebsd' or 'darwin' module). |
| 47 |
|
| 48 |
Doing this I think would allow for a much cleaner design of profiles than |
| 49 |
currently exists. As it stands, since we use both uclibc and glibc on mips, |
| 50 |
we'd have to re-replicate the entire mips profile subtrees under both |
| 51 |
default-linux/mips and uclibc/mips, and optionally under say, hardened/mips |
| 52 |
(once its features are tested). Using a more pluggable system will reduce this |
| 53 |
complexity and maintaince hassle significantly, I think. |
| 54 |
|
| 55 |
This pretty much entails a complete portage re-write I think...unsure on the |
| 56 |
specifics, but versus having to maintain a ton of profile trees, might be an |
| 57 |
idea worth discussing. |
| 58 |
|
| 59 |
|
| 60 |
--Kumba |
| 61 |
|
| 62 |
-- |
| 63 |
Gentoo/MIPS Team Lead |
| 64 |
Gentoo Foundation Board of Trustees |
| 65 |
|
| 66 |
"Such is oft the course of deeds that move the wheels of the world: small hands |
| 67 |
do them because they must, while the eyes of the great are elsewhere." --Elrond |
| 68 |
-- |
| 69 |
gentoo-releng@g.o mailing list |
Archives