[oe] SRCPV migration - How SRCPV works!

[Philip Balister]

On 11/23/2009 09:29 AM, Richard Purdie wrote:
> 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.

Given the only concrete benefit I can see is that it makes it easier for 
people using AUTOREV and git, can we examine the use case for this and 
see if there are alternatives? If this is needed for people doing 
development work, wouldn't it make more sense to focus in sdk issues?

Philip



>
>> 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
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>