On 2016-09-29 15:47, Paul Eggert wrote:
On 09/29/2016 02:15 PM, Brian Inglis wrote:
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?
Debian installs: /usr/share/zoneinfo/iso3166.tab /usr/share/zoneinfo/posixrules /usr/share/zoneinfo/leapseconds.list /usr/share/zoneinfo/zone.tab probably to support tzselect, and document leapseconds used for right, as suggested.
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.
Those other data source files are good reading, but not required unless rebuilding. Generally build sources are just downloaded by the package manager to the current directory, as that is assumed to be where you will use them.
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?
The main one is FHS Filesystem Hierarchy Standard http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html which started as Linux FSSTND then was revamped with BSD cooperation. The /run filesystem was the most significant recent addition from this group, making /var/run and /var/lock symlinks (in)to /run for legacy code. Look at systems where you have access to check details.
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.
The above document prevails on most systems, although there could be minor variations in certain items on some distributions: /etc, /usr/bin, /usr/sbin, /usr/share/man, /usr/share/zoneinfo{,/posix,/right}, and /usr/share/doc/tzdata seem to be unvarying. I don't know about BSD variants except Solaris, which still straddles the SysV/BSD divide, and OSF variants IBM AIX and HP UX, which have their own legacies, requiring some use of find ;^>
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.
As suggested, ChangeLogs provide more useful detail for packagers, admins, and those others on the list working with releases, of potential impacts by changes on their distributions and production operations. IANA, Oracle, and PHP were impacted by the changes in the latest release, and those details were clearer in the ChangeLog, but somewhat buried in the NEWS. If they are working from the IANA release, they don't have access to the ChangeLog, and should not have to clone the repo, or browse the web site, to generate it, when that could be done during packaging, as suggested. Most packages nowadays come with detailed ChangeLog history, for impact analysis. At the least, changes since the last release should be detailed, and installed into the docs directory, not the "runtime" environment. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada