[OE-core] [RFC][PATCH] linux-yocto: drop machine from SRCREV_FORMAT

[Richard Purdie]

On Tue, 2012-09-25 at 14:36 +0200, Martin Jansa wrote:
> On Tue, Sep 25, 2012 at 01:25:33PM +0100, Richard Purdie wrote:
> > On Tue, 2012-09-25 at 12:51 +0200, Martin Jansa wrote:
> > > * otherwise LOCALCOUNT is incremented after each MACHINE switch when 
> > >   machine usually has different SRCREV (e.g. because of different KBRANCH)
> > > * see http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029392.html
> > > 
> > > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> > > ---
> > >  meta/recipes-kernel/linux/linux-yocto.inc | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
> > > index 973970d..6efb578 100644
> > > --- a/meta/recipes-kernel/linux/linux-yocto.inc
> > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> > > @@ -16,7 +16,7 @@ LINUX_KERNEL_TYPE ?= "standard"
> > >  # KMETA ?= ""
> > >  KBRANCH ?= "master"
> > >  KMACHINE ?= "${MACHINE}"
> > > -SRCREV_FORMAT ?= "meta_machine" 
> > > +SRCREV_FORMAT ?= "meta" 
> > >  
> > >  LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
> > 
> > No, absolutely not. I have discussed this with Bruce before and there
> > are no guarantees that the meta branch gets updated whenever machine
> > changes. This is necessary to have deterministic builds and correctness
> > of sstate for example.
> 
> Isn't SRCREV_FORMAT used only to construct PV? So builds are still
> deterministic because SRCREV is still locked to same value?

PV is what triggers the system to rebuild. So if its not included,
rebuilds won't happen when the revisions change.

> Also PV which keeps changing without any change in source or metadata
> doesn't look deterministic to me.

I agree there is a problem, this is just not the right way to fix it,
the problem is elsewhere, likely in the git fetcher. Making the
revisions in the sqlite database respect components of STAMP/WORKDIR is
probably the way we'll end up having to fix this (so some database
entries are machine specific, some arch specific, some allarch).

Cheers,

Richard