carcassonne has asked for the wisdom of the Perl Monks concerning the following question:

Following on my recent question about running Perl on a USB key, I'd like to ask about what would constitute a minimal Perl installation that could only run one prgram that only uses:

use warnings; use strict; use File::Copy; use File::Path;

This is a bootable Linux USB key that is used to perform upgrades.

So, now my approach is to use a freshly-made LFS (Linux From Scratch) system from which I extract the configured kernel and the needed system binaries and libs (bare minimum since on each I run ldd and only include what's really needed on the USB key).

So the OS/boot part is covered. I could simply copy the whole Perl installation that's part of LFS to the USB key, but it'd be nice to save some space.

So what's really, really needed to run Perl ? I can ldd the perl executable, so that's OK. But what about all the other files ? seems important. Architecture will the same i686 (but then, would it be possible to boot on a i586 platform and Perl could still find all its required files ?).

I surely need the warnings, strict, File::Copy and File::Path modules. What else ?

Any suggestions/ideas welcomed, Al

Replies are listed 'Best First'.
Re: Minimal Perl
by tsee (Curate) on Oct 28, 2006 at 15:21 UTC

    The canonical answer to this is: A minimal perl is the full core perl!

    But since you explicitly ask for a stripped down perl, I suggest you run Module::ScanDeps (or rather which comes with the module) on the script you posted.

    Make sure to include runtime scanning, so you include the modules suggested by another poster. (Printing %INC entries)

    Additionally, you would want to have a look at which shared object files are required by those modules. can somewhat help with that, too.

    Please note that M::ScanDeps deliberately makes the choice of rather including too much than too little because it's the scanning backend for PAR. That is because many PAR users expect a simple-minded "pp -o my.exe" to produce a working stand-alone application.

    That being said, you can try out whether the script would be runnable with those modules using PAR. This should do the trick:

    pp -o test.exe -d -M Some::Module ....

    Make sure to put the perl lib into the same directory as the produced binary for testing. Also, the binary might include PAR and its dependencies which wouldn't be required for your script.

    Last but not least, I would suggest you don't trust either the %INC dump nor the results of a run because modules like File::Copy, etc. might use various other modules conditionally or, worse yet, magically. Now, the following lines of code use (at least) two modules that weren't included in the %INC dump seen in this discussion:

    my $scalar = ''; open FOO, '>', \$scalar; print FOO "Hi there\n"; close FOO;

    Looks innocent enough? Sure does. But it magically uses PerlIO(.pm) and PerlIO::scalar. If perl can't find, it throws a warning. If it can't find PerlIO/, it silently opens a file called SCALAR(XXXXXXXXX) instead of the $scalar where XXXXXXXXX is the internal address of the scalar (see "print \$scalar"). Okay, I admit, the latter is a bug in perl which was fixed in the development version.

    Perhaps this explains why people claim that the minimal runnable perl is the whole core perl. Working from that to strip the package from not-so-integral packages might work in some cases, though.

    Hope this helps!

    Update: Spelling error.

Re: Minimal Perl
by Joost (Canon) on Oct 28, 2006 at 15:01 UTC
    Well, you could kick out all the documentation and probably most modules. The list below is probably a good starting list of modules you'll need:

    perl -Mstrict -Mwarnings -MFile::Copy -mFile::Path -e'print "$_\n" for + sort keys %INC' File/ File/ File/ File/ File/Spec/ warnings/
    Also, as far as I know the "architecture" is the architecture your perl is build for, not the arch it was build on. That probably means you can't reliably run i686 perl on i586 at all. You might want to build a 486 perl if you're concerned about portability.

Re: Minimal Perl
by wazoox (Prior) on Oct 28, 2006 at 15:03 UTC
    Slightly off-topic, but why wouldn't you use some very small linux dist like Damn Small Linux or Puppy Linux? They need only 50MB, that lets plenty of room to install Perl, your modules and your files on a 512MB key. BTW a stripped-down version of Perl can be automatically installed to Puppy Linux with the PupGet utility.
      All that it does is to show the user a console with some text to which a special key is to be entered. After that everything else is automatic and the user must only acknowledge the end of the process before rebooting the machine. This is a dedicated application, not a general Linux. It could turn out that it takes equal time to strip down a DSL or Puppy (or Slax...) to make it as bare as possible. Also, that USB key is already in service and works well, albeit without Perl.

      While adding Perl, I though of doing a bit of generalization of the key and derive it from LFS instead. I already build LFS systems, of course. If not, then _that_ would take a lot of time ! ;-)

        I understand, I thought you wanted some sort of "pocket development environment", in which case something like a preconfigured PuppyLinux would rock! ;)
Re: Minimal Perl
by xdg (Monsignor) on Oct 29, 2006 at 12:30 UTC

    Do you need Perl? Or do you need to run a single Perl application? If the latter, you might consider using the pp tool from PAR to bundle it into a standalone application.


    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re: Minimal Perl
by ambrus (Abbot) on Oct 29, 2006 at 09:59 UTC

    There are a few Configure questions that may help: you can specify which modules to build.

Re: Minimal Perl
by tsee (Curate) on Oct 31, 2006 at 19:00 UTC

    There's something else I thought of which might help reduce the footprint and which didn't occurr to me when I wrote my last post.

    You can remove the POD documentation or even all comments from the modules. Naturally, you can skip all .pod files. Removing the documentation et all can be done using Adam Kennedy's Perl::Squish module.

    Apart from that, if you have some /tmp space during the run and aren't worrying too much about startup performance, you can put all modules into a .par archive which is nothing but a glorified .zip file. Then, before loading the modules, do a "use PAR '/path/to/your/par/files/*.par';". Of course, all modules required by PAR itself need to be accessible from outside such a .par distribution.

    You can even combine these two steps by using the PAR::Filter::Squish module.