Dear PAR folks,
a while ago, when I was trying to fix an issue with
PAR::Repository::Client "fallback" loading of shared libraries, I
entirely broke the shared library handling of PAR::Packer trunk. After a
very long debugging session this afternoon, it turns out that, as usual,
the bug is a trivial one. I'm glad I could finally fix this, as there
are other things waiting in the pipeline...
One of those is merging Christoph's work on dependency caching into the
main PAR::Packer release. This isn't done yet because it was blocking on
my finishing the *other* significant feature, which in turn was blocking
on the aforementioned bug.
The big news is that you can now use PAR-generated executables to run
arbitrary external Perl programs as if they were part of the package. If
that sounds to you like a glaring hole with respect to security, then
rest assured that one has to enable the feature manually during packaging:
pp --reusable -o myapp myapp.pl
# works normally
./myapp
# runs otherapp.pl with the library that myapp.pl uses
./myapp --par-options --reuse otherapp.pl
The main reason for this feature is that it's rather common for programs
written in Perl to expect a perl installation to be available. Using the
new feature, it's possible to work around that.
If you wonder why the command line to run another app looks that
obscure, then think twice under which circumstances you would want to do
that... Yes, exactly my thought: Obscure it should be.
I've uploaded a developer release of PAR::Packer (0.992_01) to PAUSE. It
should propagate to your mirrors soon. I'd very much appreciate test
reports. (Until it hits your mirror, you can fetch it and the
corresponding PAR release from
http://steffen-mueller.net/tmp/PAR-Packer-0.992_01.tar.gz
http://steffen-mueller.net/tmp/PAR-0.993.tar.gz )
Cheers,
Steffen
