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

[Jason Godfrey]

I could see a slight use case for the date when running with uncommitted
code, but I don't think that is a compelling enough case to keep the date
functionality.

- Jason
On Mon, Feb 19, 2018 at 1:54 PM Tom Russo <russo at bogodyn.org> wrote:

> 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]
> _______________________________________________
> Xastir-dev mailing list
> Xastir-dev at lists.xastir.org
> http://xastir.org/mailman/listinfo/xastir-dev
>