Re: SRCPV migration - How SRCPV works!

[Richard Purdie <rpurdie@rpsys.net>]

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 :(.

>  > 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