Re: packaging Time::OlsonTZ::Data

[gregor herrmann]

On Mon, 19 Mar 2012 18:32:40 -0600, 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.  

Thanks for the heads-up and the good news, and sorry for the late
reply.

> > 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.

Debian's feeze for the next release is planned for June, so if we
want to get the shiny new things into it, we should be quick.
 
> > 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 just took a short look at the prebuild script, and this looks
promising.

> Definitely wouldn't be a problem for Fedora to ditch
> the binary tzfiles and rebuild. But your final paragraph is even more
> enticing.

Same here, especially the last part.
I'd like to see the perl tzfiles built from the tzdata source package
completely, to avoid duplicate work, especially with stable updates.
 
> > In Debian, T:OTZ:D ought to be handled through the
> > volatile-data mechanism.  Is that OK?  

'volatile' is now called 'stable-updates', but yes, it should go
their. And since the tzdata maintainers already upload new tzdata
(and -java) packages there it would be good if they could easily
built the perl tzfiles too.

> > 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 

Exactly!


Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Billy Joel: In The Middle Of The Night


signature.asc
Description: Digital signature

Re: packaging Time::OlsonTZ::Data

[Dave Rolsky]

On Tue, 20 Mar 2012, Zefram wrote:


Dave Rolsky wrote:

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.


Yes, that's another issue I was planning to raise.  Continued DT:TZ 1.xx
releases would give distros the choice of a lengthy period in which to
switch.  There are enough 1.xx version numbers left for another couple
of years.


I wasn't planning to continue 1.xx releases after 2.00 is out. I don't 
think there's much point to doing that.



-dave

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

Re: packaging Time::OlsonTZ::Data

[Zefram]

Dave Rolsky wrote:
>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.

Yes, that's another issue I was planning to raise.  Continued DT:TZ 1.xx
releases would give distros the choice of a lengthy period in which to
switch.  There are enough 1.xx version numbers left for another couple
of years.

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

Works for me.  There's one remaining unresolved item, the zic bugs,
but if that's not resolved on the Olson end by September then I'll put
some workaround into DT:TZ:Tzfile.

-zefram

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