On Thursday 03 June 2010 18:35:29 Phil Blundell wrote: > On Thu, 2010-06-03 at 09:55 +0100, Phil Blundell wrote: > > On Thu, 2010-06-03 at 10:46 +0200, Martin Jansa wrote: > > > So will bitbake build again the same recipe (because I've built from > > > the same one before) with lower PV, just because it _still_ has the > > > highest DEFAULT_PREFERENCE and it's desired version (but still lower > > > PV because of hash, then before)?. > > > > Yes, I think so. PV, and hence P, will be different and that's about > > all that matters to bitbake. The fact that PF is the same should be > > irrelevant; I don't think any of its persistent state is keyed on that. > > I did a quick test on this and it does indeed seem to work as you would > expect. So that seems like the easiest way of solving the problem at > hand.
I probably don't know enough about the bitbake internals to see how to fix my problem with that, could you please point me in the right direction? I think in case of AUTOREV I would still need some way to automatically include a sortable revision count in PKGV, so the actual problem would only move from PV to PKGV. Or do you mean this would allow SRCPV to be removed from those hundreds of packages which don't use AUTOREV at the moment, so I can keep using AUTOREV for my own packages, without those other packages starting to cause problems? Note that my problem is not 'getting the package upgraded on the target', but 'getting automatically incrementing package versions which are consistent on several build systems'. So for me a simple workaround would be allowing BB_LOCALCOUNT_OVERRIDE to be defined per package, rather than globally. Or something similar, which would allow me to use the sortable revision count only for those packages for which I really need AUTOREV. Rgds, Pieter _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
