On 09/29/2016 02:15 PM, Brian Inglis wrote:
How about just keeping it pure data and calling it version.txt, version.list, version.version, or $PKG.version?
There are two disadvantages of that. First, the version string might happen to look like the start of a tz binary file (admittedly unlikely). Second and more important, this is a metadata file and there are likely to be future extensions (e.g., to specify the range of supported time stamps), so an extensible format is called for.
If right directories are generated, please install leapseconds.list, either at the root or under right, so we can check if right data needs regenerated when leapseconds are updated: currently Debian installs it, Centos does not, others?
Where does Debian install it?
Also if backzone is used, install that too as a flag that it was used.
We don't install other data source files (e.g., 'europe'). Perhaps there should be an option to install sources, though this is a bit unusual for software packages. If so, the option should install all the sources used.
To make life easier for distribution packagers, and admins of systems using distros, which is probably most (rather than assuming individuals installing under the generic TOPDIR=/usr/local, which now should probably be /usr/opt in most cases, and is fine for code) please consider defaulting installation to the standard "TOP" dirs: /etc, /usr/sbin, /usr/share/..., etc. (zic is normally installed in /usr/sbin), and take those variations into consideration in definitions and installation steps.
Is this standard written down anywhere?
Please also consider adding a DOCDIR=/usr/share/doc/tzdata, define the actual docs separate from MANS and COMMON, which includes Makefile (and should include version), and install the docs, MANTXTS, and HTML in DOCDIR. Some distros install some docs and some web pages, and some install none (e.g. Debian) with the data.
I suppose something like this could be done. It'd help to have a survey all the places where this stuff is installed in various operating systems.
Please also consider including your ChangeLog (from .gitignore), or generating it with git log --decorate=full (currently ~1MB: could limit it to [y-1]a..), and adding it to docs for installation: this makes it easier to see what files changed.
This I'm not so sure about. My personal ChangeLog file is merely a staging area for text intended to go into commit messages, and it's not intended to be distributed. And I'm not sure it's anyway a good idea to install commit messages into the runtime environment. Software archaeologists who want commit history can easily get it from GitHub or wherever.