DateTime::TimeZone breaking under PAR?
tjc at wintrmute.net
Mon Dec 22 23:01:51 GMT 2008
2008/12/23 Johan Lindström <johanl at darserman.com>:
> At 08:18 2008-12-22, Toby Wintermute wrote:
>> When using it via a PAR archive, it refused to determine the local
>> (This was on a Debian Etch fresh install, albeit with upgraded PAR
>> libraries, since the normal Etch ones are quite broken, and then
>> confirmed on an Ubuntu Hardy setup as well.)
> Usually when things don't work under PAR/PerlApp/etc it's dynamically loaded
> modules that weren't packaged properly.
> I see you force DateTime::Locale::en to be packaged, presumably because it
> blew up without it. But there may be other modules it needs too. Presumably
> related to the time zone stuff.
> A super quick look in DateTime::TimeZone reveals a runtime require of
> DateTime::TimeZone::* .
> What if you manually add them all to the PAR file?
> (I usually put use statements in the source for this, with a comment saying
> it's for PAR).
A couple of other people have said it's a failure of Module::ScanDeps
to correctly identify all the required modules.. Some of which are
attempted to be loaded via a string-eval..
It makes sense, I suppose, since the name of the module it attempts to
load is generated procedurally.. but is a pain.
Manually adding all the DateTime::TimeZone::* files (and while one is
at it, the TZ::Locale::* files) did indeed fix the problem.
However, this seems like a wider problem with using PAR files..
How do you detect undetected runtime requirements?
Just install *every* requirement to a private INC, then PAR it in it's entirety?
Thanks for the help,
More information about the london.pm