Re: [PATCH] Add --disable-timezone configure option

[Roland McGrath <roland at hack dot frob dot com>]

I agree that it doesn't make particular sense to keep installing tzdata as
part of libc, since nobody is actually using our copies of the data today.

As far as I'm aware there isn't yet another single packaging of tzdata
(i.e. that installs the compiled data files in .../zoneinfo/) that is
official for GNU.  OS distros seem to roll their own using the upstream
tzdata, and I don't know whether they use upstream tzcode or native tools
(i.e. glibc's zic in the case of glibc-based systems).

I don't think it would be proper to retire the tzdata from glibc until
there is a GNU or GNU-compatible package that installs the data.  The
upstream tzdata package is nothing but the data itself.  The upstream
tzcode package has no configure script, so it is not GNU-compatible.

I think somebody should make such a package, either by making a new GNU
package that tracks the upstream data reliably, or by contributing to the
upstream tz folks, and maintaining thereafter, a configure script and
whatever other changes are necessary to make it so that something directly
distributed upstream is GNU-compatible.  When that's been done, we can drop
the data from glibc's make install.  (In the meantime, it would be easy and
painless to update our data.)

In the long run, I agree it would make sense to drop the tools from glibc.
Before we consider that, we'd need to make sure that if we've made any
local changes that matter, those get folded into tzcode as appropriate.
And, as with the data, there needs to be a canonical GNU-compatible package
for these tools before we drop them from glibc.

As to the data for testing, another possibility is just to put some binary
data files into our repository.  We've avoided binary files in the
repository in the past, but IMHO that seems better than depending on
external tools for our testing.  It's also the case that we need to make
sure the library code works right with old data files, even as the
canonical tools change in the future.  (Or else, declare in each glibc
release that it requires a particular minimum standard for the tz file
format.  That is a reasonable thing to do, but only if there is a clear
canonical format specification and canonical set of tools producing it that
we can refer to.)

Conversely, we also want to ensure that in future libc versions we run
tests against the new data that people are actually using.  So if we have
data files (either binaries or source) in our repository solely for
testing, then we'll need to add new data files to the test suite over time.
If the only purpose for which we have tz data files in glibc is testing,
then it is liable to bit-rot.  So at the least we should add an
item to a release-time checklist for making sure our test suite is
adequately representative of all the tz data files out in the world with
which we mean to be compatible.


Thanks,
Roland