Mon Feb 08 17:12:49 2010: Request 42986 was acted upon.
Transaction: Correspondence added by b...@morrow.me.uk
Queue: PAR
Subject: Re: [rt.cpan.org #42986] PAR-based modules use system XS modules
over included modules
Broken in: 0.984
Severity: Important
Owner: Nobody
Requestors: t...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=42986 >
Quoth bug-...@rt.cpan.org:
> On Sun Feb 07 21:37:08 2010, TJC wrote:
> > to...@arya-tmp$ perl -MPAR sha.par
>
> Sorry, I misread your report until now - you're talking
> about a .par file, not a packed executable.
>
> I think what happens is a kind of chicken and egg problem:
>
> - your .par contains different versions of File::Temp etc
> than installed on the target machine
>
> - conceptually we would like "perl -MPAR foo.par"
> to behave like
> - extract file.par into temporary directory /tmp/foo123
> - run "perl -I/tmp/foo123 /tmp/foo123/foo.pl"
> (i.e. "/tmp/foo123" is at the start of @INC)
>
> - in order to get to the modules in the .par file, PAR.pm
> needs some modules, e.g. File::Temp
>
> - hence it already has loaded the target system's File::Temp
> before it even gets to consider the (different) copy included
> in the .par
>
> All modules cited in your report are in this category
> "required by PAR.pm to extract stuff from a .par file".
> (Digest::SHA1 is a special case that's even weirder.)
>
> Sorry, I see no sane way to make this work.
How about doing the unpacking, and then re-execing perl with exactly
that command-line? A little slow, perhaps, but PAR's startup (at least
when it has to do unpacking) isn't exactly fast anyway.
Ben
