[tz] tzdata2016g missing version information

Brian Inglis Brian.Inglis at systematicsw.ab.ca
Fri Sep 30 02:45:46 UTC 2016


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


More information about the tz mailing list