Re: [gpsd-dev] leapsecond.cache, git

[Greg Troxel]

"Eric S. Raymond" <address@hidden> writes:

>> What I meant is:
>> 
>>   have a leapseconds.cache checked in, and keep it up to date.  But call
>>   it leapseconds.cache.in
>> 
>>   during the build, if the logic wants to fetch, fetch
>>   leapseconds.cache.
>>   If not, cp leapseconds.cache.in leapseconds.cache
>> 
>> This gets your goal of up-to-date at build, and avoids modifying a file
>> From git and giving warnings about unstaged changes, which leads to one
>> typing:
>> 
>>   git reset --hard -- leapseconds.cache
>> 
>> and being told that hard reset does not work with paths.  I guess I need
>> to read the docs for reset yet again, because it's too late for reset to
>> become easy to understand ;-(
>
> OK, but under your method, how does the leapsecond update get into the 
> codebase we ship?

Someone with commit access copies the new bits into leapsecond.cache.in
and commits it.   (I don't understand why that seems tricky.)

We could have a regression test that fails when the checked in version
doesn't match the fetched version; then you'd notice.  Of course, I get
Bulletin C in email :-)

> Remember, we ship tarballs too.  One of the goals of the update method
> is to make sure that whenever anyone makes a tarball from a repo
> checkout the current BUILD_LEAPSECONDS value is up to date in
> timebase.h.

I really don't see that this is necessary.  When making a release, you
first run regression tests, and they will alarm if the checked-in
version is not up to date.  So then you fix that and do it again.  It
seems people are on top of this enough that the odds that the checked-in
version will be out of date when a release happens is approximately zero
anyway.  It seems like it took less than a week for this update, and
there were no releases :-)

And presumably there is some tarball creation procedure, and that can
also fetch, so the leapseconds.cache in the tarball will start off ok;
presumably the build-time code would prefer a successful fetch,
leapseconds.cache, and leapseconds.cache.in in that order.

> That means that something that changes on each IERS leap-second change has to 
> get
> *committed*, not just copied.

Sure, but actually committing something is just actually committing it.

My complaint is that one randomly ends up with unstaged changes, which
violates the basic notion that build procedures should treat sources as
read only.  To me this is far more important than shaving off the last
1E-5 that someone who isn't following best practices will have an old
file.

pgpimkAqSE4fq.pgp
Description: PGP signature