[oe] RFC: Improve our default conf file setup

[Chris Larson]

On Tue, Feb 23, 2010 at 10:55 AM, Richard Purdie <rpurdie at rpsys.net> wrote:
> 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?

The point I'm attempting to make is, an individual layer doesn't know
enough to make the call.  "Override the preceding" is meaningless if
you don't know what the preceding *is*.  You haven't given the
individual layer that information.  You haven't moved the
responsibility from the user (BBLAYERS) to the layer (layer.conf) as
you seemed to be implying (by noting that a given layer will be
expected to be part of a set of layers, or operate against a specific
set of layers, you imply that the responsibility doesn't belong in the
hands of the user).  You're moving part of the responsibility, not all
of it, and what responsibility you do move over is useless without the
rest of the information.  You're giving them control without
knowledge, which, as far as I can tell, won't meet any additional use
cases that a simpler mechanism wouldn't, yet does increase the amount
of setup necessary, and, therefore, more potential points of failure.
In my opinion, you're better off leaving it entirely in the hands of
the user, or entirely in the hands of the layers, not a hodgepodge of
the two.

Now, to be clear, I'm not trying to rain on your parade here.  The
patch is an improvement, absolutely, and is in the right direction for
bitbake, imo, as users would find a more project-oriented solution to
be less confusing, but I think the design needs more thought and
discussion before it goes in.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics