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