[rb-general] Source code timestamps

Ximin Luo infinity0 at debian.org
Mon Dec 5 20:52:00 CET 2016

> Ian Jackson:
>> Are the timestamps of source files part of the inputs for a
>> reproducible build ?
> I think the general answer is: it depends ;P

I think a good way of expressing this more precisely, is that it depends on whether one expects the inputs themselves to be reproducible by users/rebuilders or not.

With a .dsc or tarball, the timestamps are contained inside those packages and therefore can easily be reproduced. It's useful information to keep during the build, and it's cheap to do in Debian, so we can keep it.

With git checkouts and other methods of distributing the source code, timestamps are harder to reproduce in the source code. But people doing git checkouts (at different times) should still be able to reproduce the same things as each other. So understandably, people rebuilding via those methods would prefer timestamps to be left out.

One possible solution for GNU is to have /usr/bin/install itself support SOURCE_DATE_EPOCH and then set this timestamp for its installation targets. Then you could set SOURCE_DATE_EPOCH during the start of the build (if it's not set already by the distro) from the last entry in the ChangeLog - e.g. automake/autoconf could do this instead of every GNU package maintainer. (I seem to remember that GNU ChangeLogs don't contain the time-of-day, but you could just define this to be midnight.)

This would cause Debian to "lose" the timestamp information, for the projects that do this, but well never mind. :) Upstream developers already have this level of control over their own installation processes, anyway. I don't think we should fight against that.


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

More information about the rb-general mailing list