[OE-core] [PATCH] Add support for remote layering.
Jeremy Puhlman
jpuhlman at mvista.com
Mon Jul 11 18:45:50 UTC 2011
> 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.
More information about the Openembedded-core
mailing list