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

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3166 bytes --]

Dnia 2014-07-02, o godz. 10:44:16
William Hubbs <williamh@gentoo.org> napisał(a):

> All,
> 
> I'm moving to a new thread since the discussion has moved away from just
> a sub profile for no-multilib.
> 
> On Wed, Jul 02, 2014 at 09:30:50AM -0400, Rich Freeman wrote:
> > On Wed, Jun 25, 2014 at 4:01 PM, Andreas K. Huettel
> > <dilfridge@gentoo.org> wrote:
> > > Am Mittwoch 25 Juni 2014, 15:11:40 schrieb Rich Freeman:
> > >> On Wed, Jun 25, 2014 at 2:44 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > >> > Long story short, doing anything to Gentoo profiles is utter pain
> > >> > and comes with random breakage guarantee. Therefore, I'm asking -- nuke
> > >> > those damn profiles, and start over! The current situation is
> > >> > completely unmaintainable.
> > >>
> > >> ++
> > >>
> > >> But, would it make sense to just go the Funtoo route with "mix-ins."
> > > ++
> > >
> > > this is what we've been just discussing on the irc channel
> > 
> > So, not wanting this to die on the vine.
> > 
> > If we did the mix-in approach, would we just follow the example of Funtoo?
> > 
> > They use an arch profile, a stability profile (~arch vs arch), a
> > "flavor" profile (core, minimal, desktop), and then users can layer as
> > much other stuff on top of that as they want (gnome, kde, multimedia,
> > etc).
> 
> I think this could work for us as well, or something similar anyway.
> 
> For those who are curious, I am including the link to the flavors and
> mix-ins descriptions from the funtoo site. [1]

It's not that easy. As you can see on that site, they're supporting
much less variants than Gentoo does. In particular, they don't seem to
support non-GNU/Linux at all. No Prefix, no Hardened, no FreeBSD.

I was thinking about modularization a bit and the main issue is
handling intersecting profiles. As you can see in Funtoo, it already
starts with the 'build' flavor -- they're pretty much applying a cheap
hack (ACCEPT_KEYWORDS="${ARCH}") but such hacks can't cover all our
needs.

A simple example is CHOST. The value of CHOST depends on the arch,
often ABI, kernel, libc. Of course, we could hack this around by
creating some intermediate variables and merging them afterwards.
But not everything can be hacked around like this.

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

> > Do we want to do things the same way?
> > 
> > Some things to think about include multilib (just another arch?),
> > systemd, and usr-merge.  I'm not saying that we need to implement any
> > of that stuff completely - but when planning the profile layout we
> > should at least consider whether it will handle things like this in
> > the future.  Should some types of profiles be only additive?  Etc...
> 
> I see systemd and multilib as mix-ins, like the ones you mentioned
> above.

Multilib won't work as Funtoo-style mix-in for the simple reason it
relies on heavily on the architecture in use.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]