[Trustable-distros] [trustable-software] Provenance, git and freedesktop-sdk

Paul Sherwood paul.sherwood at codethink.co.uk
Wed Sep 26 16:23:54 BST 2018


On 2018-09-26 13:53, Ben Brewer wrote:
> Nobody has an opinion on this?

I think there are opinions, but no easy answers.

>> 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:
>> 
>> * bzip2 has no repository at all
>> * mpfr (a gcc dependency) only has an SVN repository
>> 
>> * gmp (a gcc dependency) only has a Mercurial repository

I still advocate the git.baserock.org/trove approach. The history 
matters IMO, so I'd suggest we use g.b.o for these cases by default.

>> * 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.
>> 
>> * These patches require maintenance
>> * These patches may be incorrect especially when changing versions
>> 
>> * Many projects required different versions of autotools in order
>> to build the configure file
>> 
>> * GCC requires a specific version of autoconf (2.64) to build from
>> git

Could we fix that?

>> * ucl (a dependency of SYSLINUX) requires a version of autoconf so
>> old, I've not been able to build it.
>> * 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.

Not quite... if the configure file is hosted/provided by upstream it 
means something, doesn't it?

>> * Some projects require closed source binaries to build a tar
>> release from git.

Eek... which ones?

>> * 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.

Weren't we going to move away from SYSLINUX?

>> * The dependency list for the git build is much larger (and
>> usually undocumented) than the dependency list for the tarball

I suppose if we document, it becomes documented?

>> * When updating "file" to git, I discovered that it has
>> undocumented dependencies
>> 
>> * 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.

Can/should we start raising issues on the applicable upstreams, to see 
if there is any interest in addressing them, or in us helping them to 
address them?

br
Paul




More information about the Trustable-distros mailing list