Re: reproducible built files

[Bruno Haible]

Simon Josefsson wrote:
> Oh, that is neat!  But is there any advantage compared to simply using a
> global mtime for all files in the tarball?

For the specific case of creating a tarball, I see three advantages:

  * When you pick a global mtime for all files, you need to pick it in a
    way that is somehow connected to reality. (Using 1980-01-01 for example
    is not practically useful, because it confuses every user.)
    The way you showed it
      $(git log -1 --format=%ct)
    ignores built files not under version control (e.g. bison or autoconf
    generated) and files modified by the user.

  * A typical tarball that uses the GNU Build System needs some timestamp
    ordering, in order to build without rebuilding things. In GitHub CI, for
    example, I am constrained to use
      $ sleep 1; touch aclocal.m4
      $ sleep 1; touch configure
      $ sleep 1; touch config.h.in
      $ sleep 1; touch `find . -name Makefile.in -type f`
    to enforce that order.

  * The method I'm proposing can be enabled _always_, both for the
    "reproducible" case as well as for daily use by ordinary users,
    because its results are reasonable even in that second case.

> Is there any useful use of
> mtime except for dependency tracking triggering 'make' rebuilds?

I plan to use it for the POT-Creation-Date of .pot files, created by
xgettext.

Also, when creating documentation that a user expects to be timestamped
(in a footer, like in man pages, or in an annotation, like in PDF files),
it is useful to be able to compute that timestamp in a way that
  - matches reality,
  - is reproducible,
  - does not require user intervention.

Also, remember that in some distros the 'ar' tool was crippled: it
stored zero timestamps for .o files inside .a files, thus making the
tool not POSIX compliant and breaking some Makefile rules. I wish this
could be avoided.

> Using
> the same mtime for all files in a tarball is a lot easier than curate
> another mapping of source-to-build dependency list, which seems needed
> to figure out what is the most "relevant" mtime for each individual
> generated file inside a tarball.

A tool like 'xgettext' or 'tar' can be modified to record the vmtime of
any file that it opens, and take the maximum of all of them before
writing the output. Then there is no need to manually "curate" the file list.

Bruno