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.