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.