[yocto] RFC: Backwards compatibility checking sstate-cache

Joshua Lock joshua.g.lock at linux.intel.com
Fri Sep 22 15:51:59 PDT 2017


On 22/09/17 15:00, Mike Looijmans wrote:
> I think this remark in the referenced link is the best summary of "what 
> could be improved":
> 
> """the biggest weakness of the sstate signature bits, in my opinion, is 
> that it only tracks inputs, not outputs. If task A depends on B, and the 
> metadata input to B changes, then A will be rebuilt, even if the 
> *output* of B didn't change as a result of the change to its metadata."""
> 
> For example, if someone fixes a bug in gcc that only applies to MIPS, 
> then builds that only target an ARM machine shouldn't be affected. Much 
> worse than that, I have a dependency like:
> gcc -> ... -> python -> bitstream tool -> FPGA image
> 
> so this means that a change in gcc causes Python to rebuild, which 
> causes the bitstream tool to be rebuilt and produce idential output, and 
> that triggers a roughly 31-hour build of lots of FPGA images. These are 
> the ones we really want to break. A binary output compare would help a 
> lot, even if 80% of the libraries fail to create reproducible output, I 
> may still be spared those 31 hours...
> 
> I think tracking digital output is technically feasible, and won't 
> require any change to existing recipes.
> 
> Also think about "feed" setups. When I see my settop reporting "331 
> packages need updating"... It'd be great if that could be avoided.
> 

That's what packagefeed-stability.bbclass is for. Work on binary 
reproducibility will improve things here too.

Joshua



More information about the yocto mailing list