[oe] SRCPV migration

[Koen Kooi]

On 16-11-09 13:37, Richard Purdie wrote:
> On Mon, 2009-11-16 at 13:10 +0100, Koen Kooi wrote:
>>> 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.
>
> I meant Angstrom which looks like it relies on anyone doing the updating
> to OE in general to get this right :/. As I'm sure you're aware this is
> less than ideal.

I used to spend a non-trivial amount of time cleaning up such things, 
but since I stopped caring about various recipes it isn't such a problem 
anymore.

> You have a point in that we can't lock down the local build revisions
> and this causes a problem with the distributed nature of Angstrom's
> builds.

Note that 'distributed' can mean something as simple as laptop + 
desktop. Or ubuntu-vm +fedora-vm. Or even "I wiped TMPDIR this morning".

> I think we will have to hold off some of the SRCPV migration until
> bitbake has some kind of lock down functionality for the local build
> numbers.

It would at least need a lockdown feature and a way to share 
changes/updates that is firewall friendly (basically git or http in my 
case).
I don't think forcing every distro to setup and manage their own 
database server just to make life easier for AUTOREV git users is worth 
it. I'm not saying we should make life harder for them, but screwing 
over everyone for what I would call a niche usecase (autorev users 
caring about upgradepaths) goes too far.
The current SRCREV situation sucks, but SRCPV only helps with making the 
packagemanager see that your change sorts higher and will get installed 
when upgrading. It does *NOT* solve any of the other issues, like 
needing to change PV if the new revision increased the upstream version 
(e.g. going from 2.6.31 to 2.6.32 for kernels).

> Any volunteers to write a patch?

I would guess the AUTOREV people would.

regards,

Koen