[tz] Fwd: input needed on creation of a new sub-package for raw zone data

[Brian Inglis]

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