On Mon, Jul 01, 2019 at 10:58:04AM -0500, Joshua Watt wrote: > I'm curious what people thing about all this; How important is > reproducibility? How reproducible do we want to be? How hard should it > be to have reproducible builds? What trade-offs are willing to be made > for reproducible builds? Are there smart ways we can mitigate some of > the potential performance impacts of reproducible builds?
For me 100% reproducibility isn't hard requirement, but every reproducible bit makes it more useful. Once we upgrade to newer Yocto which includes more of these fixes my plan is to achieve these milestones. 1) no changes in buildhistory reports (especially files-in-image.txt) between 2 clean builds on the same host 2) same as above, but on different hosts, but with the same OS (now we use Ubuntu 18.04 on all LGE builds) 3) same of above but with different OS on host (not important to us, but interesting to see which host differences cause differences in the target image). A) no changes in installed files (not only in their ls -l shown in the buildhistory reports), again on the same host and after it works on the same host, than maybe different hosts with the same OS and maybe then also different OS B) no changes in the .ipk files (after the packaged bits are identical) C) with the hash equivalence server we might get rid of .ipk files having different EXTENDPRAUTO from PRserv when they are rebuilt just because some dependency changed the signature. And all these milestones also have another scope axis (it's great to have everything reproducible in core-image-minimal, but there might be still a lot of differences in bigger images and our images are really big) - but again every reproducible bit helps, once the low hanging fruits are fixed, it will be easier to see what next is causing a lot of differences or even filter-out the known to be not-reproducible bits when comparing 2 images. We don't hide any source code in salt mines, so reproducing some very old binary (on possibly very different host OS) is less important for us. Similarly detecting the maliciously modified binaries is less important for us because we control the whole pipeline from source to the bits installed on the TVs. Being able to see that the diff between 2 official builds doesn't contain any unexpected changes is probably the most important aspect for us. Also in the opposite direction when QA reports new issue in the latest build and we need to compare with previous one to find the cause of it and now there is too many random changes just because the recipes were rebuilt makes it difficult to spot the significant difference which caused the new issue. > Thanks for your time. I know this was a long e-mail. Thanks for working on this, I believe this issue is really important and I really like your changes. Once we get closer to master I hope I'll be able to contribute some fixes back. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
