On Mon, Mar 19, 2012 at 2:15 PM, Zefram <[email protected]> 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. > <http://www.fysh.org/~zefram/tmp/Time-OlsonTZ-Data-0.20120201.tar.gz> 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.
