[tz] input needed on creation of a new sub-package for raw zone data
eggert at cs.ucla.edu
Wed May 24 05:23:50 UTC 2017
On 05/23/2017 12:22 PM, Brian Inglis wrote:
> From pkgs.org Fedora Rawhide tzdata-2017b-1.fc27.noarch.rpm
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
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
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.
More information about the tz