[just to debian-perl, other Cc's dropped] On 08/12/2013 01:46 PM, intrigeri wrote: > 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. wow, this seems complicated, but it's an interesting framework. If it was more formalized, i can imagine it being used for a few other data-like software libraries that are in debian (e.g. publicsuffix and its bindings in perl or other languages). Has there been any thought to formalizing this sort of structure? --dkg
Attachment:
signature.asc
Description: OpenPGP digital signature