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

[Paul Eggert]

On 05/23/2017 12:22 PM, Brian Inglis wrote:
> From pkgs.org Fedora Rawhide tzdata-2017b-1.fc27.noarch.rpm
>      /usr/share/licenses/tzdata/LICENSE
>

Ah, that's new starting in Fedora 26. I am running Fedora 25 (the current stable 
version), which does not have the LICENSE file in its rpm, which is why I didn't 
see it.

It's OK to install a LICENSE file under /usr/share/licenses. However, Patsy 
Franklin appeared to be proposing putting this file under /usr/share/zoneinfo, 
which is surely not the right place. The license should be 
/usr/share/licenses/tzdata-text/LICENSE (assuming the new package is called 
"tzdata-text"), or perhaps just in /usr/share/licenses/tzdata/LICENSE if one can 
use the same license file for different packages.

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

I'm still not following what "for their own purposes" means, if it means they 
want source text that disagrees with what's installed. What purpose would 
require that? And why isn't this purpose satisfied by simply using the 
already-existing tzdata src RPM?

After all, the set of tzdb sources is *contradictory*: parts of it disagree with 
other parts. If we merely install all the sources without instructions, 
downstream users are likely to be confused by the contradictions, and use the 
"wrong" parts.

Also, I worry that developers are under the misimpression that there is a single 
tzdb version 2017b that is the same everywhere. That's not the case, as 
different distributors deliver different versions of 2017b. If we encourage 
distributors to install source text data that disagrees with the corresponding 
binary data, we will likely cause trouble unnecessarily.

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

That problem applies to every installation of every package, and package 
managers already have mechanisms to deal with it. We need not and should not 
reinvent that wheel as part of the tz project.

> 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

Likewise: any traceability requirements apply to every file installed by every 
package. We need not and should not implement our own solution to this common 
problem. This is the responsibility of the distributor and/or the package 
manager, not of tzdb.