DateTime::TimeZone breaking under PAR?

[Toby Wintermute]

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
>> timezone.
>> (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,
Toby