[trustable-software] Provenance, git and freedesktop-sdk
Ben Brewer
ben.brewer at codethink.co.uk
Fri Sep 21 14:27:18 BST 2018
Hey All,
Recently we've been moving to have minimal-distro source elements from
freedesktop-sdk using BuildStream junctions.
As far as was practically possible we attempted to build minimal-distro
from git, while freedesktop-sdk uses tarballs for most packages.
We're currently working on the assumption that provenance is provided by
building from git source, and that this is a worthy goal to work
towards, however the practicality of this approach has become more
questionable as we've tried to implement it.
Here are the issues we've run into:
* Many projects don't have any repository, or don't have a git repository:
o bzip2 has no repository at all
o mpfr (a gcc dependency) only has an SVN repository
o gmp (a gcc dependency) only has a Mercurial repository
* In many cases, the process of building from git source to produce a
release is undocumented. In these cases a fair amount of reverse
engineering effort is required to gain parity with a tarball release.
* Many projects require patches applied on-top of git in-order to build.
o These patches require maintenance
o These patches may be incorrect especially when changing versions
* Many projects required different versions of autotools in order to
build the configure file
o GCC requires a specific version of autoconf (2.64) to build from git
o ucl (a dependency of SYSLINUX) requires a version of autoconf so
old, I've not been able to build it.
o Many git repositories contain a configure file that can't easily
be generated from the source for these reasons, and in those
cases pose the same issues for provenance that a tar file does.
* Some projects require closed source binaries to build a tar release
from git.
o SYSLINUX requires upx to build, and upx requires closed source
binaries to build properly. When building upx from git using
ucl, it prints a warning stating that it's a beta and not to be
used in production. I don't believe it's easy to trust such a build.
* The dependency list for the git build is much larger (and usually
undocumented) than the dependency list for the tarball
o When updating "file" to git, I discovered that it has
undocumented dependencies
o In many cases the increased dependencies would also be required
as part of the bootstrap, which would inflate the bootstrap size
by an impractically large amount.
The Mercurial and SVN issues can be resolved either by developing these
plugins for BuildStream or using a trove style approach where we create
a git mirror for Mercurial/SVN repositories.
The remaining issues I believe are a little more tricky to resolve.
Any thoughts or ideas are welcome.
Regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20180921/8d762f38/attachment.html>
More information about the trustable-software
mailing list