[rb-general] Source code timestamps

Ian Jackson ijackson at chiark.greenend.org.uk
Fri Dec 2 18:17:18 CET 2016

Ian Jackson writes ("Source code timestamps"):
> The effect of this is that timestamps from that source tarball are
> encoded in the output binary package.
> Do we have a way through this swamp ?

Ximin Luo wrote in the GNU thread:
> Another example is the source timestamps thing. Different people
> extracting tarballs will get the same reproducible timestamps, but
> that's not true for a git checkout (I think).

Indeed timestamps from a git checkout are not stable.  The rules are
too complex to go into here.  For RB purposes I think we need to
assume that the timestamps from git checkout are arbitrary.

>  But ideally we'd like them to reproduce the same binary outputs,
> and not different-but-reproducible outputs.

Yes.  Currently many packages just call install(8) on source files.

The only ways I can think of to make the timestamps in a .deb not
depend on the timestamps in the source tree are:

1. Reset all the timestamps in the source tree at the start of
  all builds.  This unacceptable because it breaks make.  I mention it
  for completeness.

2. Reset all the timestamps in the source tree at the start of a
  supposely-reproducible build.  I think this is undesirable because
  we want normal builds to be (in-principle) reproducible.

3. Have install(8) no longer copy the source file timestamp.  Instead,
  it would use the current time.  (Which would be smashed to the build
  epoch later.)

4. Change binary package generation to always smash all timestamps,
  not just "new" ones.

I'm not sure whether 3 or 4 is better.  4 has the advantage that we
don't need to change behaviour of a well-established tool, and that we
do not need to include installed-file timestamps in the GNU coding
standards' definition of the output.

I think we _also_ need a definition of source code which EXcludes
source timstamps.  After all the effect of source timestamps may go
beyond simply influencing installed timestamps; they may make the
build break (or reveal breakage) or something.


Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

More information about the rb-general mailing list