[oe] RFC: Improve our default conf file setup

[Richard Purdie]

On Sat, 2010-02-20 at 18:19 -0700, Chris Larson wrote:
> > I disagree but its pointless to take this further and spoil what
> > otherwise is a useful patch, we'll just add the default behaviour you
> > describe.
> 
> I see a few problems here.  First, there's more to a notion of priority than
> just 'prepend' and 'append'.  It's unlikely that a given layer will either
> way to override everything else, or be overridden by everything else.

I assume s/way/want/ above?

I agree there is more to it than that but you're arguing for a simple
default case which is just "prepend" or "append" effectively. I expect
most layers do want to override the preceding layer.

>  Second, the final resulting BBPATH will end up depending upon ordering
> anyway, because the prepend/appends will be applied based on the order of
> the parsing of the bblayer.conf files.

Most likely BBPATH and optionally BBFILE_COLLECTIONS will be appended or
prepended to which seems reasonable and BBFILES it doesn't matter.

>   Third, you seem to be retaining the
> separation between configuration file / class priority (BBPATH) and
> collection priority (BBFILE_COLLECTIONS, priority number).  Users see a
> layer/overlay/collection as a single entity, not two components whose
> interactions with everyone else may vary.

Well, the default case where there is no layer.conf file just needs to
become more complex and append to BBFILE_COLLECTIONS too then. You're
the one arguing for it :).

The default case should make them function as one I agree but where
there is a layer.conf I'd argue its up to that file to setup the righr
variables.

> If you're going to use a priority numbering scheme or something similar,
> defined by the layer, then everything should obey it, in my opinion, and
> BBPATH_prepend/append is not sufficient to reflect that priority scheme.

I propose no numbering scheme, just a convention for priorities e.g.:

Core metadata: 100
Supplementary metadata: 500
User metadata: 1000

So a user overlay would override supplementary metadata and so on
(assuming I have my numbers going the right way, I never can remember).


Take a step back again - we want a system where each overlay contains
data about what it contains and sets up bitbake's variables and any OE
specific variables to match the setup. The layer.conf in this case does
that well.

What it does badly is let the conf files know about each other so they
can fight over who does what, or let that be controlled from the
bblayers.conf file other than through ordering the BBLAYERS variable.
I'm open to ideas on how to work this better but think what I'm
proposing has ways of meeting all real world use cases?

Better ideas more than welcome!

Cheers,

Richard