_DATE__, version string, and distros

[Hal Murray]

I think we can kill two birds with one stone.

The first step is to change the code that uses __DATE__ to use the time stamp 
from autorevision.

That will solve the repro builds problem.  But it means the pivot point for 
GPS is the last commit time rather than the build time.  The GPS time scale 
is only 20 years, so somebody might want to rebuild ntpd to update that.

So the second step is to add a way to override the time stamp from 
autorevision.  That will also solve my problem of getting useful info from 
the version string.

I don't have details of how to do that.  My straw man was a script that would 
get invoked by a configure option.  But then I noticed that it gets tangled 
up with the build-repro guarantee.


If we don't want to break the build-repro guarantee, we have to put the new date into a file or update the last commit date.  If we update the last commit date, then we don't need anything special for distros.  But I can't update the last commit date to get a new version string, at least not with my current knowledge of git.

So this opens up a new can of worms.

So how do we envision that distros will use our code?  Are they going to take a tarball, or clone our git repo?  How are they going to handle local patches?  Is there a slot in the version space for a distro to indicate that they are running with local patches?  ...

If they clone our git repo, then all they have to do to update the GPS pivot is edit a file, commit that change, and turn the crank.  They can add a local file with a summary of local changes.

If they use a tarball, and/or distribute tarballs, we have to put the new-date in a file (or file metadata) or patch autorevision.cache.  I think that fits in with my script suggestion, again I haven't worked out any details.

So I guess I'm proposing a script and configure option.  That will enable distros to distribute tarballs with their patches.



-- 
These are my opinions.  I hate spam.