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.