[OE-core] populate-sysroot files in sstate cache overwritten by "empty" ones

[Richard Purdie]

On Fri, 2013-06-14 at 12:19 +0100, Mike Crowe wrote:
> On Thu, Jun 13, 2013 at 10:21:47PM +0100, Richard Purdie wrote:
> > On Thu, 2013-06-13 at 12:16 +0100, Mike Crowe wrote:
> > > The problem seems to be caused by having an ancillary task in recipe1 that
> > > depends on do_configure and the same ancillary task in recipe2 that depends
> > > on recipe1:populate-sysroot. The result is that recipe1:do_configure runs
> > > followed by recipe1:do_populate_sysroot without the intervening important
> > > tasks such as do_install.
> > 
> > Hmm, interesting.
> > 
> > There is some code in staging.bbclass:
> > 
> > BB_SETSCENE_VERIFY_FUNCTION = "sysroot_checkhashes"
> > 
> > where sysroot_checkhashes() is meant to notice that do_configure reruns
> > and hence forces do_populate_sysroot to rerun. It appears to do this
> > successfully, however its missing out the dependencies of
> > do_populate_sysroot (compile, install) which is why the package ends up
> > broken.
> > 
> > I think this is a collision of two sets of data, there are some tasks
> > being skipped which shouldn't be. So I'd guess that the values from
> > BB_SETSCENE_VERIFY_FUNCTION aren't being processed with respect to
> > removing things from the setscene covered list.
> 
> Thanks for analysing this.
> 
> What is the correct thing to happen in this situation?
> 
> Should do_configure be run but not do_populate_sysroot?
> 
> Or, should the fact that do_configure needs to be run stop the sstate
> solution from being considered valid altogether and force recipe1 to be
> compiled, installed and populate_sysroot'ed in the traditional manner?

I think this needs to stop the sstate solution from being considered
valid altogether. The reason is that the re-run of do_configure cleans
out the result of do_populate_sysroot so we have to force things to wait
for it to complete again.

(http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/staging.bbclass?id=3ab018c6254b883a6b6a61f79405dc3f8e40ad77)

Cheers,

Richard