[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