On 07/02/14 14:10, Rich Freeman wrote:
On Wed, Jul 2, 2014 at 1:54 PM, Michał Górny <mgo...@gentoo.org> wrote:
I don't feel like we ought to vote on something like this without
understanding most of the current profiles. And I'm afraid there are
only few people who have any idea about the current profile
structure...
No argument there.
We may very well still end up with something hierarchical, but we can
at least limit that to the parts of the profile where it matters.
Maybe x86/BSD and amd64/Linux and amd64/Linux-hardened need to be
interdependent. However, that still gets rid of need to deal with
desktop environments, init systems, arguments over what belongs in
@system, and so on. We could have a blocker mechanism to keep people
from mixing systemd with BSD, or we could just let people shoot
themselves in the foot.
Sounds like a good time to start reverse engineering the profiles...
Rich
The way the profiles stack via the parent file makes them difficult to
work with if they get to any significant depth. Here, for example, is
the stacking for default/linux/mips/13.0/mipsel/multilib/n32
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
*/usr/portage/profiles/arch/base
*/usr/portage/profiles/arch/mips
*/usr/portage/profiles/default/linux/mips
/usr/portage/profiles/releases
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/default/linux/mips/13.0
*/usr/portage/profiles/arch/base
*/usr/portage/profiles/arch/mips
*/usr/portage/profiles/arch/mips/mipsel
/usr/portage/profiles/default/linux/mips/13.0/mipsel
*/usr/portage/profiles/arch/base
*/usr/portage/profiles/arch/mips
*/usr/portage/profiles/arch/mips/mipsel
/usr/portage/profiles/arch/mips/mipsel/mips64el
/usr/portage/profiles/features/multilib
/usr/portage/profiles/arch/mips/mipsel/mips64el/multilib
/usr/portage/profiles/arch/mips/mipsel/mips64el/multilib/n32
/usr/portage/profiles/default/linux/mips/13.0/mipsel/multilib/n32
I put asterisks there to point out a pattern that gets pulled in
repeatedly. Sometimes this isn't a problem but sometimes this leads to
asserting something, then reverting it, then asserting it again. In the
ancient selinux profiles (circa 2009) this meant you couldn't have a
no-mutlilib amd64 system. Shallow profiles avoid this. Also "features"
avoid this (the closest thing we have to mix-ins) provided they operate
on a set of flags/packages orthogonal to the rest of the stack. You
then have shallow base and you can add as many features as you like in,
in any order, confident that one will not clobber stuff from another
since each feature is well separated.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
