[OE-core] The state of reproducible Builds

[Martin Jansa]

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.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190702/53cbb468/attachment.sig>