Iain Arnell wrote: >Of course it's technically possible, but policy-wise, everything >should be built from source.
Ah, of course. I should really be publishing the real source (build script and templates) of T:OTZ:D. Of course, the tarballs that I put on CPAN do have to include the tzfiles: the essence of the module is to package that data in a CPAN-usable way. I can't even do it by packaging the Olson data and code source files, because the Olson code is Unix-only and requires a C compiler, either requirement being a big problem for a CPAN module. > Our tzdata package doesn't always strictly follow upstream; >the maintainer sometimes incorporates proposed changes before the >official release. In such cases, T:OTZ:D should not share the files with tzdata, because T:OTZ:D follows only the canonical Olson releases. You could still package T:OTZ:D to share some files with tzdata and have others itself, if you just want to save space, but the differing update schedules are a problem. > And we'd need to introduce a strict dependency >between tzdata and T:OTZ:D - not updating one package without the >other I think that would be fine on the installation side, and in packaging it would be fine if tzdata were packaged automatically, akin to the way that I package T:OTZ:D for CPAN. But your handling of tzdata is evidently more complex than just blindly repackaging upstream, and that would play havoc with any attempt to tie T:OTZ:D to it. >I'm still thinking that the simplest and most consistent approach will >be to generate Data.pm as part of our existing tzdata build to ensure >that we're always in sync. I don't think there's any value in keeping T:OTZ:D in synch with /usr/share/zoneinfo. Its very purpose is to be consistent across platforms, independent of the host's native timezone database. DT:TZ:Local is about matching host behaviour, and with DT:TZ:Tzfile available it should be fairly easy to get it reading /usr/share/zoneinfo. -zefram
