Re: packaging Time::OlsonTZ::Data

[Dave Rolsky]

yOn Mon, 19 Mar 2012, Iain Arnell wrote:


On Mon, Mar 19, 2012 at 2:15 PM, Zefram  wrote:

Hi, I'd like to establish what's going to happen about packaging my CPAN
module Time::OlsonTZ::Data for OS distros.  I'm writing to (as far as I
can tell) the current Debian and Fedora maintainers of DateTime::TimeZone
packages, and I'm CCing the relevant perl.org mailing list.  We're now
getting close to replacing the current DateTime::TimeZone with a
rewrite that will use Time::OlsonTZ::Data as its source of Olson-derived
timezone data.


I only hope that "close" means summer or winter - not the busy periods.


This is a good question.

It's not like maintaining DT::TZ and updating it when there are new Olson 
releases is a big hassle, so I don't mind doing it for a while.


I think it'd make sense for Zefram and I to agree on a specific cutover 
date. Zefram has already released trial versions of DT::TZ with the new 
code that distros can use for testing and building new packages against.


I'll suggest September 1 as the cutover date when Zefram will release 
DateTime::TimeZone 2.00 using the new code base.


Does that seem reasonable?


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: packaging Time::OlsonTZ::Data

[Iain Arnell]

On Mon, Mar 19, 2012 at 2:15 PM, Zefram  wrote:
> Hi, I'd like to establish what's going to happen about packaging my CPAN
> module Time::OlsonTZ::Data for OS distros.  I'm writing to (as far as I
> can tell) the current Debian and Fedora maintainers of DateTime::TimeZone
> packages, and I'm CCing the relevant perl.org mailing list.  We're now
> getting close to replacing the current DateTime::TimeZone with a
> rewrite that will use Time::OlsonTZ::Data as its source of Olson-derived
> timezone data.

I only hope that "close" means summer or winter - not the busy periods.

> Iain Arnell raised an issue about T:OTZ:D not
> coming in a true source form.  I've got a new
> version of the wrapper system that I think resolves this.
>  is
> a test version of the module distribution, which bundles (the important
> parts of) the Olson database source, and the automation to build the
> tzfiles, as well as bundling the prebuilt tzfiles.  I can't not bundle
> the tzfiles, because this has to support Perl users in places where the
> Olson build code can't be used (because it's Unix-specific and requires
> a C compiler), but you can now throw away the tzfiles and build from
> proper source.  This version of the module should be a better base from
> which to customise the module, where you need to.  Please let me know
> what you think of this arrangement.

I'm in the middle of moving house at the minute, so won't be able to
take a proper look until the weekend. But this certainly seems to be
the right way to keep everyone happy at the minor cost of a slightly
larger download. Definitely wouldn't be a problem for Fedora to ditch
the binary tzfiles and rebuild. But your final paragraph is even more
enticing.

> I'll be releasing a new version of T:OTZ:D every time there's a new
> Olson database release, as I have done for the past year and a half.
> (The current version of DateTime::TimeZone is also on this release
> schedule, but the rewrite won't be, having delegated the volatility
> to T:OTZ:D.)  Sometimes Olson database updates are urgent, requiring
> promulgation on a timescale of days, and T:OTZ:D updates will inherit
> that urgency.  In Debian, T:OTZ:D ought to be handled through the
> volatile-data mechanism.  Is that OK?  In Fedora, I don't know what you
> do for such things.  Please discuss.

Fedora doesn't have a specific mechanism for volatile updates, but
there's usually no problem making DT:TZ or tzdata updates available
within a few days if necessary. The real issue is with our Enterprise
cousin that never receives DT:TZ updates.

> Somewhat interacting with the above, you have the option to apply the
> T:OTZ:D automation to a new version of the Olson database independently
> of my releases.  Iain Arnell suggested extending the existing tzdata
> package to build a matching Time/OlsonTZ/Data.pm this way, not needing
> a separate package for the module.  You'd also have it point at your
> existing tzfiles in /usr/share/zoneinfo, rather than having a separate
> copy.  That's quite feasible with the new form of the module distribution.

Bingo! I know you'd prefer that T:OTZ:D contains the canonical
upstream data, but having it as part of the system-wide tzdata package
makes things simpler and more consistent for distros where tzdata is
generally kept up to date (hopefully, RHEL7 will then have a usable
DT:TZ - even if the rest of the perl stack ends up woefully outdated).

-- 
Iain.

packaging Time::OlsonTZ::Data

[Zefram]

Hi, I'd like to establish what's going to happen about packaging my CPAN
module Time::OlsonTZ::Data for OS distros.  I'm writing to (as far as I
can tell) the current Debian and Fedora maintainers of DateTime::TimeZone
packages, and I'm CCing the relevant perl.org mailing list.  We're now
getting close to replacing the current DateTime::TimeZone with a
rewrite that will use Time::OlsonTZ::Data as its source of Olson-derived
timezone data.

Iain Arnell raised an issue about T:OTZ:D not
coming in a true source form.  I've got a new
version of the wrapper system that I think resolves this.
 is
a test version of the module distribution, which bundles (the important
parts of) the Olson database source, and the automation to build the
tzfiles, as well as bundling the prebuilt tzfiles.  I can't not bundle
the tzfiles, because this has to support Perl users in places where the
Olson build code can't be used (because it's Unix-specific and requires
a C compiler), but you can now throw away the tzfiles and build from
proper source.  This version of the module should be a better base from
which to customise the module, where you need to.  Please let me know
what you think of this arrangement.

I'll be releasing a new version of T:OTZ:D every time there's a new
Olson database release, as I have done for the past year and a half.
(The current version of DateTime::TimeZone is also on this release
schedule, but the rewrite won't be, having delegated the volatility
to T:OTZ:D.)  Sometimes Olson database updates are urgent, requiring
promulgation on a timescale of days, and T:OTZ:D updates will inherit
that urgency.  In Debian, T:OTZ:D ought to be handled through the
volatile-data mechanism.  Is that OK?  In Fedora, I don't know what you
do for such things.  Please discuss.

Somewhat interacting with the above, you have the option to apply the
T:OTZ:D automation to a new version of the Olson database independently
of my releases.  Iain Arnell suggested extending the existing tzdata
package to build a matching Time/OlsonTZ/Data.pm this way, not needing
a separate package for the module.  You'd also have it point at your
existing tzfiles in /usr/share/zoneinfo, rather than having a separate
copy.  That's quite feasible with the new form of the module distribution.

-zefram