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@gentoo.org mailing list
