On Tue, Feb 23, 2010 at 10:55 AM, Richard Purdie <[email protected]> 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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
