Re: [gentoo-dev] new profile layout with flavors and mix-ins

[Michał Górny]

Dnia 2014-07-03, o godz. 02:18:23
Joshua Kinard <kumba@g.o> napisał(a):

> [...]
>
> And so on.  The goal was to have profiles/ be extremely flat, with limited
> nesting only for categorization purposes.  Each component would contain all
> of the information specific to that component, and rely on OOP-like
> inheritance to override parent-level variables only within that component
> (although, <arch> and <kernel> would have to be a little bit more broad in
> scope).

Another sub-thread, the same question: how do you handle information
that needs to be applied to the intersection of the profiles? CHOST for
amd64 FreeBSD, for example.

> PROFILE also had a set order for the first few pieces, if only to make
> parsing and building the profile stack saner for the Portage developers:
>    PROFILE="base:<KERNEL>:<ARCH>[:<SUBARCH>]:<LIBC>:<EVERYTHING_ELSE>"
>
> base - Core Gentoo/Portage/whatever information/vars/foobar/kittens

I'm against plain 'base' since it quickly becomes a mess. I would
prefer having flavor-specific bases, like for example arch/base to mask
stuff available only in 1/2 arches and revert it in another arch/.

> kernel - Specifies the OS kernel.  At the time, only Linux existed, but
>          I *think* Debian was eyeballing kFreeBSD at the time.  So I *think*
>          I accounted for it back then.

What about kernel-ABI intersection? What about Prefix?

> arch - Machine arch-specific generic information -- doesn't handle
>        lower-level things like ISAs/ABIs/Endian, etc.
>
> subarch - Defines items specific given to given subarch of a main arch.
>           Items under this directory would carry their parent arch's
>           name for clarity only.  Again, at the time, MIPS would have been
>           the only real user of this, and, back then, it would've dealt
>           with SGI-machine-specific packages and USE flags, such as
>           differentiating an ip32 machine from an ip27 machine or a
>           cobalt.  Now that amd64/x86_64 is considering its own form of
>           n32 (x32), that would go here, and I imagine arm would
>           make heavy use of it as well.

This is a no-go for multilib support. We need to work on a consistent
arch profile tree, not more splitting.

> libc - Defines the main C library used.  A bit redundant for *BSD, because
>        they really only have one, but might help if we ever add k*BSD
>        support (such as freebsd/glibc-based or such).  For Linux...could be
>        tricky, since there are so many libc possibilities there.  I feel it
>        fits better getting defined after <SUBARCH>, especially in the case
>        of MIPS.

I think you need to handle kernel & libc in the same group.

> eapi - EAPI didn't exist back when this topic was visited.  Basically,
>        everything was EAPI=0 and there was only Portage (Paludis nor
>        pkgcore had been invented yet).

And what is this supposed to do?

> releases - I don't think this existed back then.  How it'd operate
>            nowadays, I have no idea.  Probably would contain
>            version-specific maskings for specific @system packages
>            to facilitate upgrading, and help us if we ever tried to cut
>            actual, fixed release points again (like what FreeBSD does
>            w/ -RELEASE-x.y)

I don't think releases would make any sense without heavy intersection
with other profiles.

-- 
Best regards,
Michał Górny