[tz] make rearguard_tarballs fails creates tzdataunknown-rearguard.tar.gz file with latest tzdata lzip

[Paul Eggert]

On 10/19/20 3:47 PM, Carlos Jimenez wrote:

> Before I execute "make tarballs" or "make rearguard_tarballs" the version file has the 2020c value in it.  When I run either of those commands I get the  tzdataunknown-rearguard.tar.gz file which doesn't seem correct.

I see two explanations for the behavior you observed.

1. You used a 'make' that considers a file to be out-of-date if its timestamp 
exactly equals one of its dependencies. In the tzdb-2020c.tar.lz tarball, the 
files 'version' and 'NEWS' both have the timestamp 2020-10-16 18:18:46 UTC, and 
the Makefile says that 'version' depends on 'NEWS' which means that a 'make' 
that treats equal timestamps as out-of-date will try to rebuild 'version'. Since 
you were not in a git repository the version became "unknown".

2. You copied the distribution's files, thus altering their timestamps, or 
edited one of the files for some other reason; this can cause 'make' to try to 
rebuild 'version' because its timestamp is now older than one of its 
dependencies. Again, you weren't in a git repository so the version became 
"unknown".

I doubt whether (1) was your problem since you mentioned CentOS whereas HP-UX 
'make' is the only one I know that treats equal timestamps as out-of-date. But 
'make' should do the right thing on HP-UX so I fixed (1) anyway, by installing 
the patch I mentioned in an email earlier today 
<https://mm.icann.org/pipermail/tz/2020-October/029401.html>.

Most likely your problem was (2). If so, a simple fix would be for you to build 
from an unmodified tarball without copying or changing any file; that way, the 
'version' file would have said "2020c" which would have been correct.

But suppose you needed to modify some files before running 'make'; then what? 
Here, it strikes me that the Makefile can do something nicer than just setting 
the 'version' file to "unknown". Instead, it can look at the old 'version' file, 
and append "-dirty" to its contents (if they don't already end in "-dirty"). Had 
this behavior been present in 2020c, your 'version' file would have said 
"2020c-dirty" instead of just "unknown", and that would have been more helpful.

I installed the attached patch into the development version to implement this 
idea. Please give 2020d a try now that it's out (it should fix your other 
problem), and if 2020d still has a problem please try 2020d with the attached patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-better-fallback-for-unknown-VERSION.patch
Type: text/x-patch
Size: 1440 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20201022/814913d8/0001-Use-better-fallback-for-unknown-VERSION.patch>