On 23-09-17 00:51, Joshua Lock wrote:
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.
Interesting, thanks for the hint.
That might cut down a bit on the over 4TB/month "update my box" traffic.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
Visit us at the Space Tech Expo Europe (Stand E-71)
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
