Re: SRCPV migration - How SRCPV works!

[Richard Purdie <rpurdie@rpsys.net>]

On Mon, 2009-11-23 at 14:31 +0100, Koen Kooi wrote:
> On 23-11-09 13:15, Richard Purdie wrote:
> 
> > As I understand it you'll lock locking down the local build revisions
> > with Angstrom anyway?
> 
> Dunno about that, ideally the SRCPV merge should have no impact at all 
> on existing distros, but it looks like everyone will be forced to lock 
> revisions/counts down.

How is locking the counts down using LOCALCOUNT any different to the
current situation?

> If there is a way to convert the database to a .inc file then we'd be a 
> step closer to coordinating counts between buildhosts (or rebuilds from 
> scratch).

Any method using .inc files is going to race. The only solution that is
likely to work is a single server allocating numbers in some form.

> Currently the SRCPV looks like a major step backwards to the current 
> situation unless you are on a single buildhost *and* never delete TMPDIR 
> *and* use AUTOREV *and* care about upgrade paths.

Well this clearly isn't the case. 

Its intended to be a neural step (apart from some PE issues) for
everyone except for the users of AUTOREV who it helps. Their use case is
limited to a single autobuilder model where they need to keep one file
in TMPDIR but can otherwise delete it.

> It would be a lot better if bitbake could just do the revlog | wc -l 
> trick after do_fetch has run. Or at least use that as localcount if a 
> snapshot exists in TMPDIR during parsing.

As you're more than well aware, two different behaviours depending on
whether "a snapshot exists in TMPDIR during parsing" is maintenance and
reproducibility nightmare.

The first suggestion would be nice, patches welcome.

Cheers,

Richard