Deterministic builds?

[Tom Evans]

On Sun, Nov 14, 2010 at 9:13 PM, Spörlein <uqs at spoerlein.net> wrote:
> On Sun, 14.11.2010 at 21:57:25 +0100, Erik Cederstrand wrote:
>>
>> Den 14/11/2010 kl. 21.32 skrev Dimitry Andric:
>>
>> > On 2010-11-14 21:22, Erik Cederstrand wrote:
>> >> I'm curious as to why this might be useful? Would the mtime of the
>> >> file not be be sufficient? I can only think of debugging purposes, but
>> >> apart from the timestamp, two kernels with the same rev. would be
>> >> bitwise identical,
>> >
>> > This does not have to be the case.  For example, if you have have local
>> > modifications, or use different settings in make.conf or src.conf.
>>
>> In this case the timestamp + rev. is not sufficient to reproduce the kernel anyway. You'd need to store externally the non-standard contents of conf files, local diffs etc. on all your non-standard builds. You could do all sorts of fun stuff, even fool the rev. number or timestamp if you wanted.
>>
>> I'm just saying that for the standard user on a standard GENERIC kernel (and world for that matter) - the revision number should be sufficient for e.g. filing a PR. If you need the timestamp, there's the mtime.
>
> It might not be very easy, going from revision to timestamp. It is still
> very useful to know the rough timeframe when a kernel was built, as that
> might give you the "age" of the source tree. This is of course not a
> very good mapping, and the reason we have both the revision number in
> there, but also something a human understands.
>
> If this timestamp must be fixed, my vote would be on using the timestamp
> of the svn revision the build was using as a source. But it should be
> made clear, that this is then no longer the built timestamp, but the
> source repo timestamp.
>
> Uli
>

Timestamp of the revision is better than timestamp of the build - it
is more than possible that someone could forget to update their
sources, and rebuild their kernel and world, giving a recent build
timestamp to some code that is actually quite old.

This may not be possible with the kernel, but at $JOB we wanted our
build system to produce binaries that we could precisely reproduce the
source for, so our binaries contain both the revision numbers of the
various libraries etc, but also contain any differences that the
source files had (we literally add the output of "svn diff" to an
object file generated by the Makefile). There are probably nicer ways
of doing this with the elf file format, but I don't know them :)

The important things for us are that given a binary, you should be
able to easily reproduce the source environment that the binary was
produced from, and any two binaries produced from the same sources
should be identical.

Cheers

Tom