_DATE__, version string, and distros

[Gary E. Miller]

Yo Hal!

On Mon, 17 Apr 2017 18:41:01 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

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

I'd go with optional, but either way works for me.

> 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.

Debug mode only?

> 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.

commit date is fine.

> So this opens up a new can of worms.

I'm not as worried as you.

> So how do we envision that distros will use our code?  Are they going
> to take a tarball, or clone our git repo?

Prolly 50/50.  Gentoo does both.

>  How are they going to
> handle local patches?

Not out problem.  they will be changing flags, default locations, etc.
so a user can only reproduce that exact patch set, which is what they
want.

> Is there a slot in the version space for a
> distro to indicate that they are running with local patches?  ...

Not out problem.  Every distro does that differently.  Maybe we see
a pattern after we get in a lot of distros.  We can wait for their
requests.


> 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.

That could work.

> 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.

Or just use the timestamp on the VERSION file.

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

Which is partly what we were asked for.

Maybe we have 3 cases, not all needed:

1. default to use current __DATE__ and __TIME__

2. repro build option to substitute VERSION time for __DATE__ and __TIME__

3. pull data/time from a special file.  Good for testing, otherwise
   sucky.

4. the strangest one, a dev option to use the time of the newest
   C file?  Which is what I think you want?


And none of this attacks the real problem about old binaries handling
the GPS epoch. the difference between compile time and reprotime will be
quite small.  Hours in the case of Gentoo, maybe a few years in the case
of laggards, But the problem to be solved is when a user has a 20 year
old ntpd binary.  Sadly I know where several such running instances are
now.

Maybe allow the user to put a GPS epoch in ntp.conf?  No matter how well
we guess we'll still get it wrong sometimes.  Also useful for testing.

Maybe a small script the user can run to verify current time and save in
ntp.conf.d/?
o

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170417/f1eed856/attachment.bin>