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.

> Kernel recipes are even more tricky, I bumped PE with SRCPV there too,
> but Koen warned me later (thanks again) that there needs to be consistent PE
> even between different recipes, because multiple machines can share same
> kernel recipe and machine can pick between multiple recipes with highest
> PV? Hmm now I don't understand what you mean with kernel recipes in this:
>
> <snip>
> If something needs a PE bump, make sure you do it properly and bump PE
> on the non scm fetched entries as well. For the kernel I wouldn't bump
> PE, since too many machines can use different kernel recipes.
> </snip>

Basically: if you bump PE for one kernel recipe, you need to bump PE for all of them, so I guess it should be done in e.g. kernel.bbclass or linux.inc.

Imagine I use a git kernel for 2.6.32rc6 and then add a recipe for 2.6.32, I'm fairly sure I'm going to forget to add PE in 2.6.32 the first time.

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

regards,

Koen


_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Reply via email to