[tz] input needed on creation of a new sub-package for raw zone data

[Paul Eggert]

On 05/23/2017 08:57 AM, Brian Inglis wrote:
> Almost mandatory nowadays for consideration for packaging, and avoidance
> of doubt, it states that all the files are PD, with code exceptions.

None of those exceptions apply to the proposed package, so the LICENSING 
file would be confusing and even misleading for that package.

If the proposed Red Hat package requires a LICENSING file for some 
reason, that file should simply say "This package is in the public 
domain." However, I don't see why a separate LICENSING file is needed. 
There's no such file in already-existing Red Hat packages, such as the 
tzdata package, so why is it needed in the proposed package? Besides, 
under my proposal each file in the package would contain a comment 
saying that the file is in the public domain, so any separate LICENSING 
file would be bureaucratic overkill.

> Packagers may use any of back{ward,zone} and zone{,1970}.tab generating
> their binary packages based on the reference distribution, depending on
> their policy decisions and tradeoffs of space vs backward compatibility
> with earlier releases.
> The corresponding tzdata distribution source packages can be installed
> by those who want one-for-one source.
> This (sub-)package is for those who want only the source data for other
> uses, implied by the suggested approach.

Sorry, I am not following. Are you saying that, for a particular tzdata 
version (say, 2017c), a distributor may want to ship tzdata text files 
that disagree with the same-version tzdata binary files? I don't 
understand why anybody would want to do that.

>
>>> iso3166.tab
>>> zone1970.tab
>>> zone.tab.
>> These files are already installed, and installing copies of them in a
>> different directory would lead to operational problems. How about if we
>> just leave them where they already are?
> Do we know all or any of these are installed with all binary
> distributions?

You're right that distributors can decide which packages contain these 
files. Still, it seems odd for two different packages to install the 
same files: that's a recipe for trouble. If I were the distributor, I 
would put the shared files into a separate package, which both the 
"info" and the "binary" packages would depend on. Isn't this the 
ordinary way that such conflicts are handled?


> Some distributions ship neither, and e.g. Debian ships only original
> source file leap-seconds.list, from what I can find.

Debian can of course continue to distribute leap-seconds.list for use by 
NTP. However, we can't promise to keep distributing this file as part of 
tzdb, for reasons already discussed on this list: we have problems 
accessing that file and the main reason we're still using it (instead of 
the IERS file, which is upstream) is copyright licensing hassle with the 
IERS file. So I would rather not commit to that format as part of what 
tzdata installs.

> It is the packagers job to ensure that some indication of version is
> available, and that indication is now in the version file.

No, the indication is actually elsewhere. The version file is merely a 
source-code implementation detail: it is automatically-generated during 
the build, and is deliberately not installed. In that sense it is like 
the contents of the symbolic link 
ftp://ftp.iana.org/tz/tzdata-latest.tar.gz. Packagers are of course free 
to use the contents of the version file to determine the version number, 
just as they're free to use the contents of the symbolic link to 
determine the version number. However, the version number is not needed 
during installation or operation.

> It is probably desirable for intended users (and necessary for
> packagers) to allow multiple releases to be installed simultaneously,
> with symlinks like ...-latest, or without any suffix, used operationally
> by admins, packagers, developers, or users to designate the currently
> preferred release.

Sure that's fine, and in that case the version number information is 
readily available from the names of the directories containing the data. 
There is no need for an explicit file named 'version'.

> Packagers prefer to distribute source files as is

The proposed text file is portable, so we can distribute it in the 
tzdata tarball. That way, distributors can easily ship the combined file 
as-is. The proposed text file would be treated like the 'leapseconds' 
file, which is also a portable text file that is generated automatically 
and is shipped as part of tzdata.