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

[Richard Purdie]

On Fri, 2011-07-01 at 11:43 -0700, Jeremy Puhlman wrote:
> Just a quick follow up, the part of this statement that to me is wrong,
> is it appears you are dictating work flow. While, imho, the layer
> management code which is above this level, is the place to dicate
> workflow. The patch is to core bitbake and isolated at that. This patch
> adds an additional work flow, and can be used in either state(the
> results of a current BBLAYERS setting is exactly the same today as it as
> after the patch).  More or less the patch is useful in a scope larger
> then just layer-tooling.

Let me try and convey at least one of the things I'm worrying about with
this patch. We're looking at establishing layer tooling which operate
outside of or "above" bitbake. There are a variety of reasons for that,
rightly or wrongly but this patch implies we're going to reverse that.

If we go forward with the patch and don't reverse that decision it means
that layers can sometimes be a thing that are "above" bitbake, sometimes
not depending on the circumstances. I'm trying hard to avoid that kind
of interwoven complexity as it makes code changes very hard to make in
the future and leads to frequent breakage where multiple usage methods
exist.

As an example consider the case someone calls a script asking for new
commits in layer Y to be added to flattened layer Z. We then have to add
code checking if layer Y or layer X is a "bitbake remote layer" and then
handle the updating of the layer accordingly. Can something external to
the bitbake code do that? When we extend the later tooling are we
expected to extend this code to match functionality?

The abstraction in the remote layers code isn't strong enough to cope
with that kind of interaction in its own right and I'm not sure its
possible to do that simply with a line in a bblayers.conf file and still
be readable.

So I guess my question is how do you see this moving forwards? Are you
planning to use external layer tooling at all or are you wanting
anything that external tooling can do exposed also by the bblayers.conf
URI? If this is some kind of stopgap solution for compatibility and is a
single blocking issue for Montavista that might be reasonable. If its
the start of a move to reverse the order of the stack and put bitbake at
the top and layer tooling secondary, I'm worried.

Also looking at the patch at a technical level, is there any reason to
use _layerUnpack() instead of the fetch2 unpack method? The patch is
much cleaner than it was, that much is good but needing to set so many
fetcher variables like that is a sign that worries me a little. I guess
the solution there is to code them as fallback defaults into the
fetchers themselves.

Cheers,

Richard