reproducible builds (bug report #43087)

[John W. Eaton]

From a discussion in bug report 43087
(https://savannah.gnu.org/bugs/index.php?43087), Mike Miller wrote:

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

OK, I agree these are reasonable goals.  I'm sure all the dependencies
that are required by Octave aren't there yet.

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

Yes.

> Well, if we know the first, we automatically know the second.

I do if I still have the build around.  Which of course you could
argue I should if I'm distributing and supporting it.

> IOW are
> not the full contents of config.log mainly useful for getting
> information from people who build Octave themselves?

Sure, that's also a reason that I'd like to be able to ask for
config.log, because I might want to help someone who is having trouble
even though they are using a binary that I didn't build.  Perhaps a
bug is discovered in their build that I haven't noticed but would like
to fix anyway and config.log might help me do that.

> 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?

Sure, we could probably do something like that.

> 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?

Sure, and I have no objection if you want to drop it from the Debian
package.  But until I have a better solution, I intend to install it
and leave it in the Windows binary package that I distribute.

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

I wouldn't object to having the default the other way.

>     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?

The interesting information to me is often the test failures,
especially in the case when they say "X doesn't work" and I find that
Octave was not configured to use some library and then I want to know
why that happened.  Obviously this would be a situation in which I
didn't build the binary but wanted to help diagnose the problem anyway.

jwe