Re: [PATCH] Add support for remote layering.

[Jeremy Puhlman <jpuhlman@mvista.com>]

> I am aiming for this use case to be supported with my utility. What I would 
> also like to handle though is that if you have chosen to set up some 
> configuration, then it will be able to be read in before the fetching starts.

Sounds reasonable.

>> I get it you don't want it to be automatic. Do you have something I can look
>> at that addresses the remote layering? 
> 
> I've thrown together a proof-of-concept "bitbake-fetchlayers"  in the 
> "paule/remotelayers" contrib branch:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-
> contrib/log/?h=paule/remotelayers
> 
> This is by no means a finished utility, may have hideous bugs, etc. This 
> requires nothing more than vanilla bitbake to operate. Some notes:
> 
>  * BBPATH needs to be set, LAYER_UNPACKDIR also.
> 
>  * Currently it requires conf/bitbake.conf, classes/ etc., which are shipped 
> with bitbake master but are not present with the copy of bitbake that's in 
> Poky; I hope to be able to address this in such a way that the utility does 
> not require these.
> 
>  * "init" is the command used to fetch multiple layers. I've also provided 
> "fetch" as a way to test a single fetch operation; I would expect the latter 
> to be removed at some point. (Also, none of these command names are final.)
> 
>  * Update is not yet implemented. For your use case, update is no more than a 
> re-fetch; however where you are intending to interact with the layers as SCM 
> working directories it would be better to do an update in-place. I'm still 
> thinking about how best to implement this.

I will try and check this out later this week.

>  * Output is rather noisy, this needs to be fixed also.

k.

>  * I did have to patch the fetchers as Richard suggested so they have default 
> values for the configurable fetch commands. (We'd have to have done this 
> anyway.)

Great.

> 
> I think we can support this without any issues - any of bitbake's fetchers 
> should be able to be used, including wget and local. You won't need to grab 
> oe-core first.

Okay.

> Hmm. For simplicity I've only supported fetch2 in bitbake-fetchlayers - in 
> fact it forces it at startup. It would not be hard to support fetch also, 
> however I hope we could avoid having to do so.

That is fine. The legacy code is likely not going to be moving over to
this anyways. It was more of a response to why did you do it, rather
then it needs to support it. Don't bother unless it is really needed by
someone else.


-- 
Jeremy Puhlman
Montavista Sofware, LLC.