[gentoo-releng] Profile Reorganization

[gentoo-releng] Profile Reorganization

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

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.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Profile Reorganization

[Kumba]

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

Re: [gentoo-releng] Profile Reorganization

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

On Fri, 04 Nov 2005 21:11:49 -0500 Kumba <kumba@gentoo.org> wrote:
| EPROFILE="default:linux:mips:uclibc:selinux:ip30"

Any advantage to this over a bunch of symlinks?

-- 
Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Profile Reorganization

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh schrieb:
| On Fri, 04 Nov 2005 21:11:49 -0500 Kumba <kumba@gentoo.org> wrote:
| | EPROFILE="default:linux:mips:uclibc:selinux:ip30"
|
| Any advantage to this over a bunch of symlinks?
|
AFAIK symlinks can't be handled by CVS :-/

On the other hand: Genone has an interesting proposal for multiple
entries in the profiles' "parent"-files.

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDcSxYaVNL8NrtU6IRAolQAKCdOsX5uE4MPRs3HmTYOkhm1pBcxgCfeEz9
iHUhpF3WtwaWTRtn6mcpJvM=
=ePSd
-----END PGP SIGNATURE-----
-- 
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Profile Reorganization

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

On Tue, 2005-11-08 at 23:53 +0100, Danny van Dyk wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ciaran McCreesh schrieb:
> | On Fri, 04 Nov 2005 21:11:49 -0500 Kumba <kumba@gentoo.org> wrote:
> | | EPROFILE="default:linux:mips:uclibc:selinux:ip30"
> |
> | Any advantage to this over a bunch of symlinks?
> |
> AFAIK symlinks can't be handled by CVS :-/
> 
> On the other hand: Genone has an interesting proposal for multiple
> entries in the profiles' "parent"-files.

Yeah.  The main difference is that my idea can be done by 2006.0 with no
additional support in portage, and once multiple inheritance shows up in
portage, can have the added benefit of multiple inheritances, similar to
what Joshua proposed.

Essentially, this reorganization would clean up the profile tree a bit,
and wouldn't cause any problems with future concepts going into portage
such as multiple parents.  This means that you could, for example, have
a hardened/linux/mips/uclibc/selinux/ip30 profile that inherits from the
linux mips glibc ip30 profiles.  Basically, you'd just have your
end-point profiles doing the actual inheriting, except in cases where
the end-point profile is only overriding a small part of the parent (eg.
a 2.4 sub-profile).  You would still get the mix and match abilities,
and we don't have to wait on the portage folk.  It also fits in with
what they've already got on their radar, which makes it much easier to
implement.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]