input needed on creation of a new sub-package for raw zone data
Hi, I'd appreciate community input on this plan. Ideally if others decide to also ship a similar subpackage we can use a common naming convention and install directory. We are planning to ship a new subpackage for users who want to have access to the raw zone data files e.g. leapseconds, and in a pre-determined install location e.g. /usr/share/zoneinfo/zonedata/. The raw zone data is useful for users designing their own interfaces on top of this data. The broadest flexibility is offered by the raw zone data, and while the compiled binary data is versioned and more stable, some users have expressed a request for the raw zone data. The understanding is that the raw zone data format may change. In summary: Our current plan is to use -zonedata in naming the subpackage, For example, tzdata-zonedata-2017b-1.el7. We plan to install the files in this subpackage under /usr/share/zoneinfo/zonedata/. Just as an example we would ship the following files: LICENSE version africa antarctica asia australasia europe northamerica southamerica pacificnew etcetera backward systemv factory backzone iso3166.tab leapseconds leap-seconds.list zone1970.tab zone.tab Thank you! Patsy
On 2017-05-22 07:03, Patsy Franklin wrote:
I'd appreciate community input on this plan. Ideally if others decide to also ship a similar subpackage we can use a common naming convention and install directory.
We are planning to ship a new subpackage for users who want to have access to the raw zone data files e.g. leapseconds, and in a pre-determined install location e.g. /usr/share/zoneinfo/zonedata/.
How about using /usr/share/tzdata{,-src}/ maybe with subdirectories tzdata-2017b, etc.
The raw zone data is useful for users designing their own interfaces on top of this data. The broadest flexibility is offered by the raw zone data, and while the compiled binary data is versioned and more stable, some users have expressed a request for the raw zone data. The understanding is that the raw zone data format may change.
In summary: Our current plan is to use -zonedata in naming the subpackage, For example, tzdata-zonedata-2017b-1.el7.
How about tzdata-src-2017b...?
We plan to install the files in this subpackage under /usr/share/zoneinfo/zonedata/.
Adding zonedata does not add any useful information about the contents and storing under /usr/share/zoneinfo/ could be confusing as there are already subdirectories posix and right holding copies of standard and leapsecond compensated binary data files, so TZ=posix/... and TZ=right/... are valid zones, and users may expect something similar to happen using TZ=zonedata/... which would be unfortunate.
Just as an example we would ship the following files: LICENSE version africa antarctica asia australasia europe northamerica southamerica pacificnew etcetera backward systemv factory backzone iso3166.tab leapseconds leap-seconds.list zone1970.tab zone.tab
README, CONTRIBUTING, NEWS, and Theory should be included, also tz-how-to.html which documents how to define and use the sources. leap-seconds.list should be a (symbolic?) link to the canonical file version leap-seconds.<timestamp> e.g. leap-seconds.3692908800. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Yes. Packagers: Please keep it compatible with what iana tarball updaters (such as tzupdater, various language packages) expect but as a directory: minimal changes maximize portable reusability and minimize support/maintenance for everyone. And please don't collide file hierarchy by breaking existing conventions but make it sensible like: /usr/share/iana-tzinfo-src/latest --symlink-> /usr/share/iana-tzinfo-src/20NNz This makes it unambiguous about what it is what and allows for rolling-release upgrades without breaking production processes that cannot survive system "static" shared data files randomly disappearing beneath them. Barry Allard On Mon, May 22, 2017 at 10:54 AM Brian Inglis < Brian.Inglis@systematicsw.ab.ca> wrote:
On 2017-05-22 07:03, Patsy Franklin wrote:
I'd appreciate community input on this plan. Ideally if others decide to also ship a similar subpackage we can use a common naming convention and install directory.
We are planning to ship a new subpackage for users who want to have access to the raw zone data files e.g. leapseconds, and in a pre-determined install location e.g. /usr/share/zoneinfo/zonedata/.
How about using /usr/share/tzdata{,-src}/ maybe with subdirectories tzdata-2017b, etc.
The raw zone data is useful for users designing their own interfaces on top of this data. The broadest flexibility is offered by the raw zone data, and while the compiled binary data is versioned and more stable, some users have expressed a request for the raw zone data. The understanding is that the raw zone data format may change.
In summary: Our current plan is to use -zonedata in naming the subpackage, For example, tzdata-zonedata-2017b-1.el7.
How about tzdata-src-2017b...?
We plan to install the files in this subpackage under /usr/share/zoneinfo/zonedata/.
Adding zonedata does not add any useful information about the contents and storing under /usr/share/zoneinfo/ could be confusing as there are already subdirectories posix and right holding copies of standard and leapsecond compensated binary data files, so TZ=posix/... and TZ=right/... are valid zones, and users may expect something similar to happen using TZ=zonedata/... which would be unfortunate.
Just as an example we would ship the following files: LICENSE version africa antarctica asia australasia europe northamerica southamerica pacificnew etcetera backward systemv factory backzone iso3166.tab leapseconds leap-seconds.list zone1970.tab zone.tab
README, CONTRIBUTING, NEWS, and Theory should be included, also tz-how-to.html which documents how to define and use the sources. leap-seconds.list should be a (symbolic?) link to the canonical file version leap-seconds.<timestamp> e.g. leap-seconds.3692908800.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Patsy Franklin wrote:
We are planning to ship a new subpackage for users who want to have access to the raw zone data files e.g. leapseconds
This is a good idea overall; thanks. Here are some comments and suggestions for improvement. First, as a terminology issue, we need a better name than "raw zone data". The files we're talking about are ordinary text files, and "raw" has the wrong connotation for text. Also, the package name "tzdata-zonedata" is repetitive and somewhat-confusing. Instead, how about a package name like "tzdata-info" or "tzdata-src" or something like that?
Just as an example we would ship the following files: LICENSE
The LICENSE file conveys misleading information for the files in question, as they are all public domain, so let's not install it. Of course if you want to install all the source files as a package, then LICENSE should be included along with all the other files in the tzdb tarball; but as I understand it, the goal here is to install only the data source.
africa antarctica asia australasia europe northamerica southamerica pacificnew etcetera backward systemv factory backzone
The installed source data should match the installed binary data, so the above list of files needs to be adjusted to match what's installed as binary data. For example, by default 'backzone' should be omitted since its data items are normally not installed. Also, that's a long list of file names. I would rather not propagate implementation details like this list into the installation directory. Although the intent may be that "the raw zone data format may change", in practice what happens is that people depend on the format. So we might as well use a simple format rather than a complicated one; see below for a specific proposal.
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?
leapseconds leap-seconds.list
We need not and probably should not ship two text files that contain the same leap-second info in different representations. As we're considering removing leap-seconds.list anyway, let's just install 'leapseconds' and skip leap-seconds.list.
version
I would rather that we didn't recommend installing this file in the tzdb source, as that would be a maintenance hassle and anyway the file is not needed to generate the binary data. Similarly, I don't think the installation directory's name should contain the tzdb version number, as others have proposed. Versioning should be an independent aspect of operations, and it should not be our job. With the above in mind, here's a simpler proposal: We optionally install two text files: 'leapseconds' and a new file 'tzdata.zi' containing the parts of asia, australasia, etc. that are actually used to create the binary data. The idea is that 'zic tzdata.zi' exactly re-creates the installed binary data files, and that 'zic -l leapseconds tzdata.zi' does the same for data with leap seconds. Programs that want text rather than binary data can read tzdata.zi (and optionally, 'leapseconds'). Because tzdata.zi uses the documented zic format, third-party tools can parse it. (".zi" stands for "zoneinfo": ".zi" is to zic as :.c: is to cc.) We can install these two text files by default into the same directory as the already-installed text files iso3166.tab, zone1970.tab, and zone.tab.
On 2017-05-23 02:29, Paul Eggert wrote:
We are planning to ship a new subpackage for users who want to have access to the raw zone data files e.g. leapseconds
This is a good idea overall; thanks. Here are some comments and suggestions for improvement.
First, as a terminology issue, we need a better name than "raw zone data". The files we're talking about are ordinary text files, and "raw" has the wrong connotation for text. Also, the package name "tzdata-zonedata" is repetitive and somewhat-confusing. Instead, how about a package name like "tzdata-info" or "tzdata-src" or something like that?
Or tzdata-source, although Debian packagers may balk at that usage, as RH packagers balk at tzdata-src.
Just as an example we would ship the following files: LICENSE The LICENSE file conveys misleading information for the files in question, as they are all public domain, so let's not install it. Of course if you want to install all the source files as a package, then LICENSE should be included along with all the other files in the tzdb tarball; but as I understand it, the goal here is to install only the data source.
Almost mandatory nowadays for consideration for packaging, and avoidance of doubt, it states that all the files are PD, with code exceptions.
africa antarctica asia australasia europe northamerica southamerica pacificnew etcetera backward systemv factory backzone
The installed source data should match the installed binary data, so the above list of files needs to be adjusted to match what's installed as binary data. For example, by default 'backzone' should be omitted since its data items are normally not installed.
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.
Also, that's a long list of file names. I would rather not propagate implementation details like this list into the installation directory. Although the intent may be that "the raw zone data format may change", in practice what happens is that people depend on the format. So we might as well use a simple format rather than a complicated one; see below for a specific proposal.
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? This proposed package is effectively a data only developer package for those who do not use the reference distribution code, and for various reasons may not want to have the source code on their systems.
leapseconds leap-seconds.list
We need not and probably should not ship two text files that contain the same leap-second info in different representations. As we're considering removing leap-seconds.list anyway, let's just install 'leapseconds' and skip leap-seconds.list.
Some distributions ship neither, and e.g. Debian ships only original source file leap-seconds.list, from what I can find. In conformance with NTP crypto file guidelines, which is why this file is generated and how it is intended to be propagated, the canonical name is leap-seconds.<timestamp> where <timestamp> is the NTP time stamp for the file generation time, allowing for checking whether this is the latest proventic generation, soft linked to a generic name, in this case leap-seconds.list.
version
I would rather that we didn't recommend installing this file in the tzdb source, as that would be a maintenance hassle and anyway the file is not needed to generate the binary data. Similarly, I don't think the installation directory's name should contain the tzdb version number, as others have proposed. Versioning should be an independent aspect of operations, and it should not be our job.
It is the packagers job to ensure that some indication of version is available, and that indication is now in the version file. 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.
With the above in mind, here's a simpler proposal: We optionally install two text files: 'leapseconds' and a new file 'tzdata.zi' containing the parts of asia, australasia, etc. that are actually used to create the binary data.
The idea is that 'zic tzdata.zi' exactly re-creates the installed binary data files, and that 'zic -l leapseconds tzdata.zi' does the same for data with leap seconds. Programs that want text rather than binary data can read tzdata.zi (and optionally, 'leapseconds'). Because tzdata.zi uses the documented zic format, third-party tools can parse it. (".zi" stands for "zoneinfo": ".zi" is to zic as :.c: is to cc.)
Packagers prefer to distribute source files as is, and as the intent of this (sub-)package is presumably to allow users to develop other products based on the data files, or possibly further subset them, as for embedded distributions, original file names, sizes, and timestamps ensure that no files or data are missing from the package.
We can install these two text files by default into the same directory as the already-installed text files iso3166.tab, zone1970.tab, and zone.tab.
As all files are currently available in the original and distribution source packages corresponding to the tzdata binary packages, there are other requirements from the requesters implied by installation into a distinct directory only the source data files, sufficient for a major vendor distributor to plan on releasing separate packages. These could be used by downstream language packagers e.g. ghc, java, dotnet, mono, python, ruby, etc. in their ...-tzdata-... packages, as well as by embedded distribution or application packagers, e.g. Oracle, etc., who may have to maintain a strictly documented long term audit trail from original source data to selected source data to generated binary data, to meet standards and for financial and government systems and applications. Requests about how to handle some of these requirements have been posted on the list. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
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.
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
On May 23, 2017, at 3:22 PM, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> wrote:
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.
That makes sense. The right way to consider licenses is that the absence of a stated license means there is no license (no rights to use at all). A one line file that says "this whole package is in the public domain" would serve. Or if that's not completely accurate, it should say "with the exception of x, y, and z, this package is in the public domain". And using LICENSE as the name for that file makes sense because that's what people expect to look for. paul
On 2017-05-23 14:23, Paul.Koning@dell.com wrote:
On May 23, 2017, at 3:22 PM, Brian Inglis wrote: 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. That makes sense. The right way to consider licenses is that the absence of a stated license means there is no license (no rights to use at all). A one line file that says "this whole package is in the public domain" would serve. Or if that's not completely accurate, it should say "with the exception of x, y, and z, this package is in the public domain".
That is, unfortunately, exactly the legal European situation, where no rights may be waived, only explicitly granted by all copyright holders, and there exists no public domain, except after copyright expiry. Europeans are mostly not yet used to thinking in those novel terms, so there are now problems with packages and contributions, often resolved by granting CC or equivalent licences. I believe that is why tz uses the PD NIST leap seconds file, as the IERS file(s) do not have explicit licences or rights grants.
And using LICENSE as the name for that file makes sense because that's what people expect to look for.
In the Commonwealth of Nations that is a verb and the noun LICENCE is preferred ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
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.
On 05/22/2017 06:03 AM, Patsy Franklin wrote:
africa antarctica asia australasia europe northamerica southamerica pacificnew etcetera backward systemv factory backzone
To help simplify the construction of source packages like this, I've written a proposed patch, archived here: http://mm.icann.org/pipermail/tz/2017-May/025079.html This patch will let the package contain just one text file, 'tzdata.zi', instead of the above thirteen text files. The single file consumes only 124 KiB of storage instead of 708 KiB (on my machine, at least). The storage savings comes partly from omitting comments and white space, partly from abbreviations, and partly from avoiding fragmentation.
Paul and Brian, Thank you for all the input on my request! Paul, I'm reviewing your proposed patch and the resulting data file. I'll get back to you with feedback ASAP. Sincerely appreciate your help with this! -Patsy On Wed, May 24, 2017 at 10:53 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 05/22/2017 06:03 AM, Patsy Franklin wrote:
africa antarctica asia australasia europe northamerica southamerica pacificnew etcetera backward systemv factory backzone
To help simplify the construction of source packages like this, I've written a proposed patch, archived here:
http://mm.icann.org/pipermail/tz/2017-May/025079.html
This patch will let the package contain just one text file, 'tzdata.zi', instead of the above thirteen text files. The single file consumes only 124 KiB of storage instead of 708 KiB (on my machine, at least). The storage savings comes partly from omitting comments and white space, partly from abbreviations, and partly from avoiding fragmentation.
participants (5)
-
Barry Allard -
Brian Inglis -
Patsy Franklin -
Paul Eggert -
Paul.Koning＠dell.com