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

[Brian Inglis]

On 2017-05-23 11:20, Paul Eggert wrote:
> 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.

>From pkgs.org Fedora Rawhide tzdata-2017b-1.fc27.noarch.rpm
    /usr/share/doc/tzdata/README
    /usr/share/doc/tzdata/Theory
    /usr/share/doc/tzdata/tz-link.html
    /usr/share/licenses/tzdata/LICENSE

Many people and companies are wary of using code, data, or software
nowadays without knowing explicit rights to any collection.

>> 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.

The distribution source package contains the sources corresponding to
the distribution binary package.
The proposed package target users want to make use of the source data
for their own purposes, independent of the binaries used by the system.
For that reason, the proposed package should probably install each
release in independent subdirectories rather than replacing existing
data, and possibly update a generic symlink to point to the latest
installed, or leave it to the admin, or whatever controls the system
build e.g. ansible, chef, docker, puppet, etc.

>>>> 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?

Or just install from either in a common location.
Probably depends on packaging policy, tools, and how many common files
are involved - may not be worth generating a separate package for a few
files that have no independent function.

>> 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.

We are talking about tzdata packages where Debian ships only the
original leap-seconds.list in the binary package /usr/share/zoneinfo/,
not the leapseconds file generated by leapseconds.awk, and they ship
none of the mentioned docs or html files. Fedora tzdata binary packages
contain no leap seconds files even though they contain the right/ binaries.

>> 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 would be useful for traceability to have the data and generation tool
release and files and options used embedded in each binary data file -
including whether backward, backzone, which zone.tab, and which leap
seconds data was used.

>> 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'.

It should be easier for users to find than figuring out that date is
connected to zoneinfo is provided by tzdata, and the docs are in
/usr/share/doc/, and checking the changelog or NEWS, if distributed or
provided, or using the package manager to query the installed tzdata
release.

>> 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.

It is redundant as the existing continent and ocean files contain the
required information, and is likely to be ignored by packaging tool
specs which select files from unzipped archives to include in downstream
packages.
As already mentioned, whether or which leap seconds file may be
distributed varies.
Some package sources contain only those original source files required
to build the package binaries provided.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada