[OE-core] [PATCH 1/1] bbclass/sstate: only allowed sstate-cache objects are allowed in a build (read-only sstate-cache)

[Richard Purdie]

Hi Hongxu,

On Thu, 2014-08-21 at 10:36 +0800, Hongxu Jia wrote:
> The requirement is the developer who demand only the "new" software
> they write is allowed to be compiled from source, they only want to
> reuse binaries from an existed sstate-cache, if the developer makes
> a change that triggers a rebuild, it should be an instant error.
> 
> The purpose of this is for the sstate-cache to check if the item
> exists or not. If it doesn't the item needs to be in a whitelist
> or we need to fail.
> 
> In the sstate-cache code, add a checking in the return path of
> sstate_checkhashes. If read-only sstate-cache enable, and the
> recipe's ${PN} not in the ${SSTATECACHE_WHITELIST}, it trigered
> an instant error.
> 
> ...
> $ bitbake db
> ERROR: Read-only sstate-cache is enabled, the build of
> "db rpm-native gcc-runtime eglibc linux-libc-headers libgcc"
> did not come from sstate-cache. Only the recipe listed in
> SSTATECACHE_WHITELIST is allowed to build from source
> 
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Sorry for the delay in getting to this, with the other patches for the
release, time has been difficult.

I have been able to take a look at this and the other locked sstate
patches I've had pending for some time.

Having thought quite a bit about this, I think we really want to make
this functionality part of the siggen class code. Where we need to add
hooks, we should do so with callbacks into the siggen code.

I've just sent out a patch which my locked code in it. Could you take a
look and see if we can make that approach work with your code too?

In particular, I don't really want to have multiple whitelist type
variables. Could we use the SIGGEN_LOCKEDSIGS variable as the definitive
way to control which recipes can float and which should not?

Cheers,

Richard