Re: [PATCH] Add support for remote layering.

[Paul Eggleton <paul.eggleton@linux.intel.com>]

Returning a discussion that has begun on the wiki to the mailing list:

Jeremy Puhlman wrote:
> Paul Eggleton wrote:
>> A good start but naturally we want to avoid the bits that hard-code
>> variable values. I wonder about situations where people want their own
>> versions of layers or to share remote layers (e.g. between an oe-core setup
>> and a poky setup); however people can just use local layers for this.
>
> In reality they are setting "reasonable" defaults. Hardcoding implies
> something that is unchangeable. All the values are "set if unset", so they
> can be changed in the bblayers.conf file. Prior to the introduction of
> layers, all the values were hardcoded, just in a bitbake.conf file, so you
> always had working fetchers. With out that the fetchers are basically broken
> until after you have loaded up the layers. Given the fact that nearly every
> bitbake.conf file contains the same settings for defining fetchcmd and a like,
> simply having a reasonable default setting for the things the fetchers need
> is not really that terrible an idea irrespective of the remote layering.

I think it's just about the placing of these defaults, I don't necessarily 
object to having them in the first place. My main concerns are around the 
defaults for variables like TMPDIR which may end up actually being used in 
preference to what the user has set in local.conf. Obviously we have a 
chicken-and-egg situation where we depend on having the main layer present to 
read any configuration other than bblayers.conf - perhaps this indicates we 
need to restructure some of the config files if we want to make this work 
nicely.

> As for the second question. I have some content tools that I am cleaning up
> that basically provide methods for defining layers and groups of layers
> together for mirroring and sharing. That might address what your talking
> about there. They work along with the patch posted here, but could be
> modified to output things a bit differently if needed.

I'd definitely be interested in seeing these tools and trying to incorporate 
them into what we're doing for layer tooling in 1.1. Is there a lot of work 
left to do before you can release these?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre