Deterministic builds?

Spörlein uqs at spoerlein.net
Sun Nov 14 21:13:38 UTC 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3853 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20101114/64e96deb/smime.bin


More information about the freebsd-hackers mailing list