[OE-core] [PATCH] Add support for remote layering.

Jeremy Puhlman jpuhlman at mvista.com
Fri May 20 17:42:47 UTC 2011


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

So with regard to the code specifically:

TMPDIR really is the only major offender there as far as I can tell, all
the other variables are set in the local copy of the data and disappar
after the fetch. That variable setting could get moved over to the local
copy as well, though we would need to change the way LAYER_REMOTE_STASH
and LAYER_UNPACKDIR are set to make sure they are correct for the rest
of the parse but that is not a big deal. Or we could set those via
something relative other then TMPDIR, TOPDIR perhaps.

General case:

In reality looking at the bulk of the settings there, there are a couple
different groups there.

There is the stuff to make the fetchers work. I think those should
probably make their way in to the the code in general. Setifunset means
they can be changed early(bblayers), or overridden with the first
bitbake.conf and in general they are rarely used in any user
configurations(local.conf) or at least shouldn't. Having working
fetchers from the first parsed line of configuration data seems like a
generally good idea, but that is just me.

There is the stuff only related to the fiddling with remote layers,
which I talked above, can be changed to use any location in general.

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

Work this week has been a bit slammed. Hopefully I will be able to post
something this weekend, maybe Monday.




More information about the Openembedded-core mailing list