[Octave-bug-tracker] [bug #43087] improve support for reproducible builds

[Mike Miller]

Follow-up Comment #2, bug #43087 (project octave):

Ok, first I'll explain where I was coming from and why this is harmful. The
perspective is deterministic or reproducible builds, so given a source
snapshot that has not changed, the output should look the same. I should be
able to execute the build procedure on a given platform with the correct set
of build dependencies, and the output should look bit-identical with what I
got last week, or even with what someone else on a different machine got, also
with the same exact build dependencies. MXE is actually a really good example,
since it encodes exact details about every single dependency. So given a
snapshot of MXE, everybody's resulting installer should look bit-identical.

So you could argue that config.log looks identical each time, but keep in mind
that it includes things like the hostname, the build timestamp, the user's
PATH, the user's source/build directories. If I build mxe-octave in /home/mike
and you build it in /home/jwe, should we not still end up with the same
binary? If we do have otherwise reproducible builds, config.log is still not
deterministic and all these variables are irrelevant noise.

It sounds like there are two main things you want to capture with the
config.log. First, is this from some well-known official distribution, let's
say, is this Octave as built by me or by foo. The second is how exactly was
Octave built.

Well, if we know the first, we automatically know the second. IOW are not the
full contents of config.log mainly useful for getting information from people
who build Octave themselves? The first case might be better solved using file
hashes, which I think most Linux distributions already do for the contents of
all of their packages. If the file hashes are not as expected, then show me
your config.log. Does the Windows installer give us a way to verify the
contents of the payload after it has been installed, or can we add a manifest
to it such that it is possible, maybe even make it something that the user can
run in Octave or click on the GUI?

Do you agree that the full contents of config.log are not that useful for
builds of Octave that are built by a distributor, because we already have
other ways of seeing/reproducing how it was built? We really just want to
know, are you using one of these known builds of Octave and has anything been
modified since it was installed?

A couple possible compromises:

* configure option to disable installing config.log? Default would be no, so
self-built users would have it by default, distributions would have to know to
turn it off. Not great, but I could live with it.

* create a sanitized version of config.log, or a configure summary file that
could be installed that would only represent the things that are indeed
constant from build to build? Is there some minimal set of information that
you would still consider useful that would not include machine-specific
details or timestamps or every single test compilation and error message?

I have some Debian specifics for the Debian bug so I'll comment there
separately.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?43087>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/