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