Version Strings - doesn't show recent edits

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> I consider the current setup to be close to useless.  If I go through the 
> typical edit, build, test cycle, the string doesn't get updated so I can't 
> tell if I'm running the version from git or something with local 
> modifications.
> 
> I gather there is a constraint from distros.  They want the binaries they 
> ship to be identical to what you would get it you pulled their sources and 
> built your own.  That means we can't use __DATE__ or __TIME__.
> 
> Will the distros be happy if we have a configure option (default off) to use 
> the build time?
> 
> ------
> 
> There is another worm in this can: issue #268
>   Waf uses current date and time breaking repro builds
> 
> > That time stamp is only used by the NMEA driver. I assume it's trying to
> > recover from the GPS 1024 week rollover. I'd be happy to throw all that code
> > out and tell people to use GPSD if they have a device that old.

This whole area is a mess in which I have been unable to think up a
policy that makes me entirely happy.  We're going to have to choose
one thing to prioritize at the expense of other annoyances.

It would be possible, with some hackery, to bump the version string on
every edit.  However, this would mean that every single build would always
recompile every file that included the generated version symbol.  This
would be irritating, especially given the existence of slow buildbots;
qemu images for exotic architectures would be right out.

That is why the usual policy these days is to *not do that* and say
that if you want a version string that fine-grained you look at HEAD's
git hash.  Or run git-describe on it.

There are two distinct uses of current date and time in the build.  One
is dispensable, maybe.  The other is not.

The indispensable one is the use in the NMEA driver. In theory we
could bow to the distros' desire for reproducible builds, throw that code
out, and pass the buck to GPSD.  I don't want to do that because, as they
say in politics, the optics would be bad.

It's the same reason I fought against dropping filtering on named
interfaces - we're on dangerous ground any time we throw away a
functional feature that some grognard time admin somewhere might have
been relying on for 15 years.  I feel safe in doing that only if we
have a very convincing security/reliability reason to give, and
appeasing distros' policy guidelines *doesn't qualify*.

The maybe-dispensible one is the use of build-time pivoting to find the
nearest time corresponding to an l_fp across ntp-date calendar cycles.
If we toss that we lose the ability for ntpd binaries built in different
eras (but within a half-cycle of each other) to settle on a common timebase
and interoperate.

In theory we could replace that use with a timestamp that freezes at
each point-release time (GPSD does this).  So, if a sysdamin updates
from our point source releases conscientiously, no problem.  Do you
want to bet on everybody doing that, nobody recompiling the same
source release multiple to throw it on multiple machines?  I
don't. The really security-consious admins (our core demographic, as
it were) don't trust anything they haven't buit from cryptosigned
sources with a toolchain they control and trust.

Now, suppose we give the distros a no-__DATE__/__TIME_ option.  Then
that's what they're going to ship.  Cross-era interoperability goes
poof, and nobody who cares about it is going to be much appeased
by the argument that their distro package could have been built
to (at least partly) handle that case.

This may seem like an academic issue now, with end of era 0 still
19 years off.  I don't think it's going to be acadenic at all in the
two or three years around the era rollover.

I think we have to tell any distro that brings this up that we can't
comply because doing so would create a serious risk of breaking a
core assumption of RFC5905.  While I'm not looking forward to being in
that argument, still less am I loving the blowback I think we'd get
if we knocked that central column out of Dave Mills's cathedral.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.