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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
