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