On Mon, Oct 10, 2011 at 11:10 AM, Zefram <[email protected]> wrote: > Iain Arnell wrote: >> we can't simply repackage T:OTZ:D from CPAN as it >>contains precompiled tz files. > > I don't see why you can't. The tz files are platform-neutral.
Of course it's technically possible, but policy-wise, everything should be built from source. Admittedly, we do cheat a little with DT:TZ, but generated perl code is more acceptable than tz blobs. > >> And it doesn't make sense for use to >>rebuild the whole thing from source as we already have a tzdata >>package that contains exactly the same data and is updated regularly. > > I thought about that. I think the clever way to package it is to make > the package depend on the existing tzdata package, not include the > files that are identical to those in tzdata, and have its installation > script set up hard links from the tzdata files. That would give you a > completely normal version of the Perl module, which finds the tz files > in the Perl module tree as normal, while actually sharing storage with > the tz files that libc uses. > > You must, of course, ensure that the tz files are actually bit-for-bit > identical in order to make this trick valid. They will be as long as > you're using the Olson zic to generate your tzdata package. Yeah, I thought of that approach too, but there's at least a couple of problems. Our tzdata package doesn't always strictly follow upstream; the maintainer sometimes incorporates proposed changes before the official release. And we'd need to introduce a strict dependency between tzdata and T:OTZ:D - not updating one package without the other (effectively forcing the tzdata maintainer to update both packages, or accept delays as separate maintainers coordinate their efforts). 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. And then if we're creating our own Data.pm anyway, we might as well point it at /usr/share/zoneinfo rather than build a forest of symlinks in vendorlib. And, of course, anyone can still install the real T:OTZ:D from CPAN if they're that way inclined. > Anyway, to answer your direct question: no, the code that builds a > T:OTZ:D release is not public. I'm approaching switching to git, at > which point I'll most likely publish repos, which in the T:OTZ:D case > will include the automatic build code. And this is (most likely) good news. -- Iain.
