Re: SRCPV migration - How SRCPV works!

[Philip Balister <philip@balister.org>]

On 11/23/2009 07:15 AM, Richard Purdie wrote:
> On Mon, 2009-11-23 at 09:07 +0100, Koen Kooi wrote:
>> On 22-11-09 20:05, Martin Jansa wrote:
>>
>>> Every git recipe in OE tree should have some sane hash stored in
>>> conf/distro/include/sane-srcrevs.inc
>>
>> The cabal decided that checksums are "part of the metadata" and belongs
>> in the recipes. I don't understand why SRCREVs are so different. For
>> SRCREVs my life would be a lot easier if all SRCREV where put in their
>> respective recipes. Distros can always do
>>
>> SRCREV_pn-foo = "bar"
>> PV_pn-foo = "1.2.3+gitr$SRCPV"
>>
>> in their distro.conf if needed. Due to scoping we do need some include
>> for EFL_SRCREV, since those recipes are tightly tied together.
>
> FWIW I dislike it that we have SRCREVs elsewhere. There is a problem
> (bug?) with bitbake that makes this necessary though and that bug is
> hard to fix :(.

The difference between checksums and SRCREV's is that there is one 
checksum per file, but different distro's may use different versions of 
the same software.

As Koen noted a little later, before SRCPV goes into dev, it should be 
well worked out. I'm finding the email threads hard to follow :(

Philip


>
>>   >  But be carefull with persistent cache file
>>   >  something like this:
>>   >  tmpdir-dev-shr/cache/om-gta02/bb_persist_data.sqlite
>>
>> So if I build pixman_git.bb for om-gta02 weekly, but monthly for
>> beagleboard or om-gta01 I'll also get different numbers, right?
>> I think the count should only be in a machine specific database if the
>> SRC_URI/SRCREV is machine specific.
>
> As I understand it you'll lock locking down the local build revisions
> with Angstrom anyway?
>
> If we try and solve every issue all at once with this, I doubt we're
> going to get anywhere fast. If we take the issues one at a time and chip
> away at them we may end up somewhere better.
>
> The whole SRCREV thing is a can of worms. Its no secret I dislike the
> thing and the fact we've never had a totally clean way to implement it.
> I also recognise its useful though, I use it myself :/. SRCPV is a step
> to fixing a number of problems, we just need to be careful we don't
> create many others.
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>