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

[Joshua Kinard <kumba@gentoo.org>]

On 07/02/2014 13:54, Michał Górny wrote:
> Dnia 2014-07-02, o godz. 10:44:16
[snip]
> 
> 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...
> 

I am going to throw this out there and see what people think.  Maybe it's
insane, maybe it's not, maybe it's a mix of insane and not-insane.

Years ago, before we had the current stacking profile design (we were
discussing the current design, actually), I kinda conjured up this "building
blocks" like approach for a profile design.  Basically building on how most
of a Gentoo system is pieced together in /etc/make.conf (or wherever that
file lives now).  A new variable, $PROFILE, would be defined that contains a
colon-separated list of profile "blocks" that specifies the nature of the
system.  Kinda like how $PATH is built.  This idea never got any traction,
though, and may still not.

Quoting from an e-mail I sent months ago to blueness after reading one of
his blog posts, here's what I worked out years ago with some updated
thinking a few months ago:

----------------------

An idea I had at the time, but which never gained any traction, was to use a
similar profile layout as we have now, but not treat it like a sequence of
directory structures.  Instead, the idea was to have it modeled more like
how $PATH is built up from discrete components.

So instead of something like this:

    /usr/portage/profiles/base
    /usr/portage/profiles/default/linux
    /usr/portage/profiles/arch/base
    /usr/portage/profiles/features/multilib
    /usr/portage/profiles/features/multilib/lib32
    /usr/portage/profiles/arch/amd64
    /usr/portage/profiles/releases
    /usr/portage/profiles/eapi-5-files
    /usr/portage/profiles/releases/13.0
    /usr/portage/profiles/hardened/linux
    /usr/portage/profiles/hardened/linux/amd64
    /usr/portage/profiles/targets/desktop
    /usr/portage/profiles/hardened/linux/amd64/destkop

You would have a layout in /usr/portage/profiles look like this instead
(btw, this is from long-term memory, so some things might be off from my
original idea way back when):

   arch/               base/            desktops/
     |-amd64/                             |-e17/
     |-arm/                               |-kde/
     |-mips/                              |-gnome/
     |-sparc/                             |-xfce/
     |-x86/

   eapi/             kernel/            libc/
     |-3/              |-freebsd/         |-glibc
     |-4/              |-linux/           |-uclibc
     |-5/                                 |-musl
     |-6/                                 |-freebsd

   options/          releases/          roles/
     |-hardened/       |-11.0/            |-desktop/
     |-multilib/       |-12.0/            |-firewall/
                       |-13.0/            |-ids/
                       |-freebsd-9.2/     |-router/
                                          |-server/

   servers/          subarch/
     |-dns/            |-mips-o32
     |-file/           |-mips-n32
     |-mail/           |-sparc-v8
     |-www/            |-amd64-x32

The idea being that, in /etc/make.conf (or wherever that file is now), you'd
define $PROFILE like this:

linux-mips o32 uclibc server:
PROFILE="base:kernel/linux:arch/mips:subarch/mips-o32:libc/uclibc:roles/server:releases/13.0"

linux-amd64/x86_64/x64 glibc hardened 13.0 KDE desktop:
PROFILE="base:kernel/linux:arch/amd64:libc/glibc:roles/desktop:options/hardened:desktops/kde:releases/13.0"

freebsd-amd64 9.2 firewall:
PROFILE="base:kernel/freebsd:arch/amd64:libc/freebsd:roles/firewall:releases/freebsd-9.2"

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).

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

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.

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.

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.

desktops - Settings for specific desktops if "roles/desktop" is specified
           in $PROFILE.

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).

options - Was a different name back then.  Basically, hardened was the only
          alternate mode available back then.  Multilib hadn't even been
          thought of, because MIPS was the only arch that even had to worry
          about it, and most people were both scared and confused by the
          thought of multiple ABIs.

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)

roles - Just thought this one up, as back then, we only had desktop and
        server.  It'd basically define a minimal set of recommended
        packages necessary to qualify that role.  I.e., desktop/kde
        would install KDE, Qt, and other related packages, while ids/
        would install say, snort and tcpdump for packet inspection.

servers - Like "desktops" above, defines minimal settings for specific
          server types.  So "servers/www" would drag in apache, and
          "servers/dns" would attempt to pull in BIND.  Obviously,
          there would need to be a way to override the core software
          element for a given server role -- Maybe USE flags could be
          modified to handle this (so that -apache +lighthttpd swaps
          apache out for lighthttpd).  Needs a lot more thinking on
          this one.

----------------------

Thoughts?

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic