Re: SRCPV migration

[Koen Kooi <k.kooi@student.utwente.nl>]

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