Re: [PATCH] Add support for remote layering.

From: Jeremy Puhlman <jpuhlman@mvista.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] Add support for remote layering.
Date: Fri, 01 Jul 2011 10:17:22 -0700	[thread overview]
Message-ID: <4E0E0122.5070801@mvista.com> (raw)
In-Reply-To: <201107011424.27821.paul.eggleton@linux.intel.com>

On 7/1/2011 6:24 AM, Paul Eggleton wrote:
> Hi Jeremy
> 
> Have looked at this further and I really think this needs to be a separate 
> utility, but one still written in python using bitbake's infrastructure (like 
> bitbake-layers). The advantages of this approach:
> 
> 1) Avoids reworking bitbake's initialisation and avoids possible re-execution.

Neither of those are issues in the current patch. Setting up the
fetchers so they work, inside a local copy of the data is hardly
reworking the initialization.

> A separate utility can take advantage of a full parse and utilise all of the 
> user's configuration.

This is certainly the case, however in the time that we have used this
type of structure we have never needed all of the config data because
you are always more less very early in the process. More or less you
could create a bitbake-layers style "utilty" with the current patch. In
the current patch, there is only a single line of code in the cooker,
everything else is competely isolated.

> 2) Fetching/updating layers should be (able to be) a conscious action rather 
> than something that happens implicitly as part of the build process

This seems rather arbitrary. As noted this is not some theoretical
process that I am proposing. We have tons of customers already use, and
have used this type of model for a very long time. While I can certainly
see the advantages of an external tool, why is it an either or? the
reality is with the current patch, we already have bitbake-layers style
utility. Its called bitbake. :) Run it with no argument and the first
thing it does is fetch everything.

> I'm trying to put something together that does this at the moment, with a view 
> to there being components that allow integration with the content tools you 
> posted earlier. Will keep you posted.

For what it is worth, I would still like to see something like the patch
get integrated. The single line in the cooker could be surrounnded by a
BB_ var, and you more or less wouldn't know the difference. Also if
BBLAYERS is just directories like it is now, every line is more or less
ignored and passed back untouched.

-- 
Jeremy Puhlman
Montavista Sofware, LLC.