Fwd: input needed on creation of a new sub-package for raw zone data
Sorry, should have replied to all on this one. ---------- Forwarded message ---------- From: Patsy Franklin <pfrankli@redhat.com> Date: Tue, May 23, 2017 at 9:26 AM Subject: Re: [tz] input needed on creation of a new sub-package for raw zone data To: Brian.Inglis@systematicsw.ab.ca Hi Brian, Thanks for the feedback! On Mon, May 22, 2017 at 1:54 PM, 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.
We really want to avoid using src to prevent any confusion between the full src rpm that we ship and this subset of the zone data.
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 already provide tzdata-2017b-1.el7.src.rpm which contains the full set of sources. The location of these sources is defined by the installer.
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.
That's a good point. I hadn't considered that case. We chose zonedata to clarify that it was only the zone data - not zic, zdump, binaries, etc. It was requested that we provide this subset of files in a consistent location at install time which is why we grouped it under the zoneinfo directory. Is there a more appropriate place to install it? Do you have any other suggestions for a name since I think src is ambiguous for our purposes?
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.
We ship README and Theory with the base package. CONTRIBUTING, NEWS and tz-how-to.html is shipped with our src package. Do we still need to duplicate these in the optional subpackages? BTW, I forgot to mention that our spec file will not allow the new subpackage to be installed without the corresponding version of the base package. The base package does not require the optional new subpackage but will check to insure that it is in sync if it is installed. Do we still need to version the leap-seconds file if it is tied to a specific tzdata version? Thanks! Patsy
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On 2017-05-23 07:30, Patsy Franklin wrote:
Sorry, should have replied to all on this one. On Mon, May 22, 2017 at 1:54 PM, Brian Inglis 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. We really want to avoid using src to prevent any confusion between the full src rpm that we ship and this subset of the zone data. 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 already provide tzdata-2017b-1.el7.src.rpm which contains the full set of sources. The location of these sources is defined by the installer. 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. That's a good point. I hadn't considered that case. We chose zonedata to clarify that it was only the zone data - not zic, zdump, binaries, etc. It was requested that we provide this subset of files in a consistent location at install time which is why we grouped it under the zoneinfo directory. Is there a more appropriate place to install it?
/usr/share/tzdata{,-src,-source}
Do you have any other suggestions for a name since I think src is ambiguous for our purposes?
tzdata-source
> 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. We ship README and Theory with the base package. CONTRIBUTING, NEWS and tz-how-to.html is shipped with our src package. Do we still need to duplicate these in the optional subpackages?
BTW, I forgot to mention that our spec file will not allow the new subpackage to be installed without the corresponding version of the base package. The base package does not require the optional new subpackage but will check to insure that it is in sync if it is installed.
This is effectively an alternate source (sub-)package, so should include all relevant files from the source package not in the binary: NEWS and how to are relevant, CONTRIBUTING is desirable.
Do we still need to version the leap-seconds file if it is tied to a specific tzdata version?
Guess you should only ship what was in the original source. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
participants (2)
-
Brian Inglis -
Patsy Franklin