[oe] SRCPV migration - How SRCPV works!

Richard Purdie rpurdie at rpsys.net
Mon Nov 23 12:00:32 UTC 2009


On Mon, 2009-11-23 at 12:42 +0100, Martin Jansa wrote:
> RP or someone else:
> 
> What do you think about proposed implementation?
> 
> Another table with localcount for every revision built, not only for last
> one.
> 
> And table with last revisions with branch and machine in key?

Keeping history is actually quite pointless. The only thing you can use
it for is to make PV go backwards which is exactly what we're trying to
avoid.

The machine specific part is a massive nightmare and my advise is simple
- don't use different revisions for different machines, this is simply
not designed to work. Worst case you create a locked down version for
one of the machines.

> Then script for persistent cache upgrade or upgrade it while building if
> new table with localname will have have new name and if not found there,
> bitbake will try in oldtable and safe result to new one.

This is getting way too complicated for a set of hypothetical situations
nobody is likely to use. Lets try and keep this simple.

The core problem is that nobody has created a way to share the persist
data between build machines. The agreed workaround was to add a way for
the revisions to be locked down though configuration and we're on our
way to do this.

Cheers,

Richard





More information about the Openembedded-devel mailing list