Re: AUTOREV and SRCPV

[pieterg <pieterg@gmx.com>]

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