[Xastir-dev] Value of "compilation date" in a source-built Xastir?

[Tom Russo]

This was brought to my attention today:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890651

There is an attempt by Debian to keep builds completely reproducible, for
what appear to be really good reasons (see https://reproducible-builds.org/).

Xastir's build system will create a file "compiledate.c" every time you build
it, with the current date and time in it.  This feature was added in 2006
as a result of a patch from a user, in commit bf89457.  By doing that,
we make builds NOT reproducible in the sense desired.

They propose that we change our makefile to allow this timestamp to be 
overridden via an environment variable, so they can simply feed an standard
date into it and have us use that instead of the date/time that the compilation
is run.

But before I (or Dave Hibberd, the Debian maintaner) go ahead and open a
bug report to do this, I would like to open a more general philosophical
discussion:  if you follow the various links about reproducible builds, faking 
out the compile date is actually sort of a second-best approach: the better 
one is not to include the compile date in the code in the first place.  I
propose we take that better approach.

Back in 2006, since we were using CVS and there was no single way to say "this 
build was created using THIS code," using the compilation date was a moderately
helpful way to check whether the Xastir you were running was up to date,
by checking the Help->About box and seeing how old the build was.  This
was particularly helpful if you were running code right out of CVS, because
the version number was pretty meaningless, and there was no single revision
number to point to to show which revision you had built (every single file in 
CVS had its own revision number).  

But now, code built from a release source tarball has a meaningful version 
number and always has (so the compile date is irrelevant), and as of commit 
ba3b807, any code built out of a git clone has the git SHA-1 hash that was 
actually built encoded into the About box, in parentheses next to the somewhat 
meaningless version number that only indicates "the next release in 
development."  The git SHA uniquely indicates what repository state you're 
looking at or building, so this is pretty close to what the original 
use case for the compile date was.

So it seems to me that instead of applying a patch like the one attached to
the debian bug report above, the more permanent and completely portable
solution to the reproducible build issue would be to STOP putting the 
compilation date into the binary altogether.  (The actual patch in the debian 
bug report isn't portable as it relies on linuxisms and GNU Make, so needs 
a little bit of work if we want to go in the direction of patching up the 
build).

My position is that the compilation date is a poor substitute for "is the code 
I compiled current?" given that we're now actually saying "this code was built 
from THIS repository state."  If we stop using it altogether and rely instead 
on the version number and git sha (if and only if the code was built
out of a git clone), the build is reproducible by default.  So I think that's 
what we should do.

Any thoughts one way or another?  Is there anyone who was really still 
depending on the build date in the About box for anything?

-- 
Tom Russo    KM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]