On 16-11-09 12:39, Richard Purdie wrote:
On Mon, 2009-11-16 at 11:59 +0100, Koen Kooi wrote:
On 16-11-09 11:49, Richard Purdie wrote:
On Mon, 2009-11-16 at 11:37 +0100, Koen Kooi wrote:
So basically every recipe that is using SRCPV in PV or PR is unsuitable
to be put in online feeds. That should be enough to stop the SRCPV merge
into .dev.
How is this different to the current situation though?
In the current situation (actually, last weeks situation) SRCPV was
never used.
If SRCREV is locked down you will get 1 as the local build revision back
and it will not change and will be the same for everyone.
If its not locked down, all bets are off but they always have been - no
change.
Ah, that was the bit of info I was missing. But if SRCREV is locked down
(as it should!) what's the point of putting SRCPV in PV or PR? It seems
to make things worse if you update a locked SRCREV, since SRCPV will
remain '1'.
How does Angstrom currently solve this problem? You bump the SRCREV and
override PV manually?
With 'angstrom' you mean 'oe', right? If a SRCREV gets updated the
person doing that checks if PV or PR need to get changed to make it sort
higher (or lower, depending on the change). I don't see how SRCPV will
make life or less error-prone. By the looks of it it only makes things
worse.
regards,
Koen
Angstrom would probably need a policy of wiping out the persistent data
DB so it didn't auto increase and then the situation doesn't change (for
Angstrom).
The benefit of this change is that local builds start automatically
working for people with fixed or floating SRCREV (and allows easily
switching between them) and people generating feeds from a single build
machine also benefit.
What we really need is a way to force the "local" build revisions for
the likes of Angstrom, I'll keep that in mind for the next bitbake
release...
Cheers,
Richard
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
