If you're not using perlbrew to manage your Perl installations, you're missing out. You can leave the moldy old system Perl 5 as is and use a supported and modern version of Perl 5 for your current applications. You can even use separate installations for separate applications.
The only drawback I've ever had with
perlbrew is that upgrading
my main development version of Perl 5 in place (from 5.14.0 to 5.14.1 to
5.14.2) required the reinstallation of a few hundred CPAN distributions. That
shouldn't be an onerous task, but it is for two reasons:
- I don't have a canonical list of every dependency in every active project in a single place; I've had to make every project reinstall its dependencies, which is busywork
- It's unnecessary, as minor releases of Perl 5 compiled with the same characteristics (64-bit, non-threaded in my case) are binary compatible with each other, so XS components are compatible
I've noticed that binary distributions of Perl 5 tend to share
@INC directories between versions, so why not
As it turns out, this is a compilation option to Perl 5 itself. The
otherlibdirs option adds a directory to
@INC as included
perl binary itself.
perlbrew allows you to
-D options, so my invocation looked like:
perlbrew install -j 9 perl-5.14.2 -D otherlibdirs="$PERLBREW_ROOT/perls/perl-5.14.1/lib/site_perl/5.14.1"
-j 9 option performs a parallel build and test.
Sharing the site_perl directories between 5.14.1 and 5.14.2 saved me a lot of time, but I did notice one caveat: any distribution which installs helper programs (, Pod::PseudoPod::Book) doesn't automatically make those helper programs available. I had to fix that by installing those distributions by hand. That was the work of seconds, not hours, so it's still an improvement.
Again, this trick only works if the new build has the same binary characteristics as the old build. If you're using the same build options on the same machine for a Perl 5 in the same major version family, you should be fine.