Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Kumba]

Andrew Gaffney wrote:
>
> This is pretty much exactly what Kumba was talking about. I didn't like
> the idea simply because it allowed the user to shoot themselves in the
> foot way too easily. It will also cause QA problems, since the profiles
> wouldn't be strictly controlled by the arch teams and releng anymore.

Just so it's clear, this is mostly what I was thinking up a few years ago when 
what is the current profiling system was being figured out (back when we had 
separate profile folders for everything -- ~2004.x timeframe).  ferringb quickly 
pointed a few flaws with letting the user have complete control over the 
ordering, and so I revised my idea to have the base components fixed in a 
specific order like so:

base:os:arch:userland

So a mips-unknown-linux-uclibc user would set a profile much like:
	PORTAGE_PROFILE="base:linux:mips:uclibc:"

FreeBSD/x86 user might use:
	PORTAGE_PROFILE="base:freebsd:x86:bsdlibc"

And so on.  This would fix the core components' order in a specific way.  Once 
the four base elements are set, the user is free to add on "extra" nodes that 
add or enhance the functionality of the core profile.  Like hardened or 
embedded, for example. (base:linux:x86:glibc:hardened)

Antarus added another idea on earlier today that'd make it more robust by making 
the nodes have depends, and via that, portage can yell at the user if they mix 
something improperly, say they have a glibc userland, and they try to add the 
embedded profile.  Since the idea of embedded with glibc is a bit silly 
(Although not impossible), portage can do one of two things: yell at the user 
that they need to switch to a uclibc userland, or ignore using the embedded 
node, because embedded depends on uclibc.

My thinking in all of this is to make the profile/ folder layout a little saner, 
but this idea has really only existed as just an idea.  It's not had a really 
good looking at by some of the portage experts aside from ferringb or antarus -- 
and they quickly highlighted several shortcomings.  In a way, though, I kind of 
envision profiles/ looking somewhat like this (Sample):

profiles/
   |
   |--base/
   |
   |--abi/
   |   |
   |   |--n32/
   |   |--o32/
   |   |--v9/
   |
   |--arch/
   |   |
   |   |--mips/
   |   |--sparc/
   |   |--x86/
   |
   |--endian/
   |   |
   |   |--be/
   |   |--le/
   |
   |--os/
   |   |
   |   |--linux/
   |   |--freebsd/
   |
   |--threads/
   |   |
   |   |--linuxthreads/
   |   |--nptl/
   |
   |--userland/
   |   |
   |   |--bsdlibc/
   |   |--glibc/
   |   |--uclibc/
   |
   |--xtra/
   |   |
   |   |--embedded/
   |   |--hardened/

Most arches I can imagine won't make use of half the nodes listed here, as some 
are restricted in what they can do.  Most of it is based on my experiences in 
trying to devise future expandibility for the mips arch, as there are about a 
zillion different ways to string things together for us, like so:

base:linux:mips:glibc:n32:nptl:be (mips big-endian, glibc, NPTL, N32 ABI)
base:linux:mips:uclibc:o32:linuxthreads:le:embedded (mips little-endian, uclibc, 
linuxthreads, embedded, O32 ABI)
base:linux:mips:uclibc:n32:nptl:be (mips big-endian, uclibc, NPTL, N32 ABI)

And so on.  Of course, not all of them are used, but it's a bad habit of mine to 
think that far ahead into the future.  Most of this is made up as I go along. 
None of it has ever really been put down in writing, except one version that 
Antarus examined a few months ago in what he called "Mix n' Match", or "Mixin" 
form, and as more people ponder this idea and either shoot holes through it or 
add on more ways to better implement it, I guess will determine whether or not 
it'll ever be feasible.

I think if properly implemented right, it might allow for some degree of control 
by the user while letting the devs keep users from completely shooting their own 
legs off at the knee joint, and make the profile system more robust and saner to 
manage.


Thoughts?


--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-dev@g.o mailing list