Re: The State of the TimeZone in Debian
Hi,
> Reviewing your libtime-olsontz-data-perl, I'm afraid your patch
> doesn't do enough. You've made the Perl module use the tzfiles from
> /usr/share/zoneinfo at runtime, so it gets whatever version of the files
> is currently installed as part of the tzdata package, but the rest of
> the module has baked-in metadata for a particular version of tzdata.
> You must do something to ensure that the module serves metadata for the
> same version of tzdata that is installed.
ACK.
> The prebuild script, which you said you don't want to touch, is what
> generates the Perl source form of the metadata, based on the Olson
> database source. To do without prebuild entirely, you'd have to get the
> metadata into Perl form in some other way. Some of it (country-based zone
> selection data) is available under /usr/share/zoneinfo in a different
> form, but some (directional link data) is not. So it's not feasible
> to implement Time::OlsonTZ::Data correctly based entirely on data from
> the tzdata package as it currently exists. It would be a somewhat bad
> idea even if tzdata were minimally modified to make it possible: you'd
> be applying logic from Time::OlsonTZ::Download at runtime, somewhat
> inefficiently.
> A sensible approach really requires that you run the prebuild script
> against each version of the Olson database. You can use the wrapper
> part of Time-OlsonTZ-Data (from a CPAN version that you're happy with,
> eviscerated by "./prebuild bare") and apply it to each new Olson database
> version yourself, duplicating what I'd do to make a new version of
> Time-OlsonTZ-Data for CPAN. Your options really revolve around how you
> split data between the tzdata and libtime-olsontz-data-perl packages
> and how the packages are coupled.
Right.
> If you keep the metadata in the Time/OlsonTZ/Data.pm file,
> and keep the file in the libtime-olsontz-data-perl package, then
> libtime-olsontz-data-perl needs to declare that it depends on an exact
> version of tzdata. E.g., libtime-olsontz-data-perl 0.201304 depends
> on tzdata=2013d. Generally, any arrangement that has versioned data in
> both packages needs such a dependency declaration, in one direction or
> the other, to ensure that the packages upgrade in lockstep.
> Other options involve putting all the versioned data in the tzdata
> package.
In my understanding, what we're trying to avoid is the need to update
another package than tzdata, so that makes more sense to us.
> You'd keep the wrapper part of the Time-OlsonTZ-Data source
> around as build-helping code for the tzdata package. When building a
> new version of tzdata you'd apply the prebuild script to generate what
> amounts to the Time/OlsonTZ/Data.pm file, from its template, and then
> install that file as part of the tzdata package. In the simplest version,
> you generate the actual Time/OlsonTZ/Data.pm file, and install it directly
> into a Perl module directory. The libtime-olsontz-data-perl package could
> actually be superfluous that way. Another way, libtime-olsontz-data-perl
> installs a Time/OlsonTZ/Data.pm file that doesn't contain metadata itself
> but invokes the Perl file from the tzdata package to acquire it.
We've investigated this solution with Gregor, and here's what we came
up with (well, at least it's the best I could come up with from the
notes I had -- Gregor, don't hesitate correcting me if needed):
1. Factor out tzsrc.meta generation into a dedicated sub, that's
called from sub action_download_olson.
2. Add a prebuild action that generates tzsrc.meta from local source
(probably by using
Time::OlsonTZ::Download->new_from_local_source), that in practice
will be provided by the tzdata source package.
3. Factor out Data.pm etc. generation from build data: build data
tries to generate stuff we don't want. This results in a new
`build_Data.pm' prebuild action.
4. Upload to Debian a package called libtime-olsontz-data-perl-src,
that contains basically what you get after running `./prebuild
bare' + tzsrc.meta.
5. Have the tzdata source package build-depend on
libtime-olsontz-data-perl-src.
6. When building the tzdata package, build Data.pm using `./prebuild
build_Data.pm' and ship it in a Perl module directory.
Does it make sense? Did we miss anything? Any better idea?
I guess other OS than Debian might make good use of this too. Zefram,
are you interested to do the needed refactoring in Time::OlsonTZ::*?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
Reply to: