On 9 February 2018 at 23:11, Paul Eggert <eggert@cs.ucla.edu> wrote:
Since zic/make is not run, how is a downstream consumer going to use them
A process at joda.org, threeten.org, etc. can run 'make' to generate a tarball that contains files in rearguard format, and then joda.org, threeten.org etc. can redistribute that tarball.
To be clear here, as the maintainer of the project, you are effectively asking some of its key consumers to fork the project. I find that pretty astonishing. The tzdb project has provided a distribution of the relevant data in a suitable form for consumption for 20 years or so. It still does today, as the change is currently rolled back. I'm certainly not about to go replicating the tzdb distribution, placing large amount of work and cost on me, merely to work around a change that simply should not be happening. Mark Davis has recently expressed this again in another thread - there is absolutely no good rationale for making this change, and it clearly causes major pain. The only effect on zic is a flag that everyone seems to agree is pointless/deprecated, and some disagree that the change is correct wrt the flag's specification. A rational observer would be astonished that this issue got beyond 20 emails never mind 200. If zic wants to reverse the dst flag, it should do so. The source files should remain with positive SAVE values. Stephen
Assuming the current development version, the process could run something like the following, say.
make rearguard.zi mkdir tzrear.dir ln rearguard.zi tzrear.dir/africa for file in antarctica asia australasia europe northamerica southamerica etcetera systemv factory backward ; do \ touch tzrear.dir/$file || exit; \ done (cd tzrear.dir && \ tar -cf - africa antarctica asia australasia europe northamerica southamerica etcetera systemv factory backward ) | \ gzip >tzrear2018c.tar.gz
No doubt this will require minor tweaking to pacify whatever quirks OpenJDK has, but I hope you get the idea.
The point is that if OpenJDK wants a particular tweak to the format, then it should be in charge of its own destiny, and not be at the mercy of upstream changes. This is what other distributors do, and it's a good time for OpenJDK to start following their lead.