Is installing modules in site_perl by setting installdir=site sufficient protection

Using site_perl should be ok (though I'm not entirely sure how exactly Red Hat is packaging their stuff), but as site_perl would typically be later in the default @INC, you'd have to change that temporarily in order for your own module versions to be found (in your development environment) in case there are competing versions.

Anyhow, the common advice is to stay away from the system Perl entirely, and install your own Perl in some other directory (e.g. /usr/local/...). That way, you can mess with it any way you like without impeding the system Perl or being impeded by system upgrades.  (When you build your own perl on that box, make sure to configure it to not include existing lib directories (of the system Perl) into the default @INC of the newly built perl (as is the configure default).)

Anyhow, the common advice is to stay away from the system Perl entirely, and install your own Perl in some other directory (e.g. /usr/local/...). That way, you can mess with it any way you like without impeding the system Perl or being impeded by system upgrades. (When you build your own perl on that box, make sure to configure it to not include existing lib directories (of the system Perl) into the default @INC of the newly built perl (as is the configure default).)

This is good advice, but not always easy to follow, because if you build your own perl, and then add the extra perl modules you need from CPAN, then it takes a long time, and you can sometimes hit dependency hell. This is especially problematic if you install something bleeding edge with lots of dependencies such as Catalyst

On the other hand, if you rely on the distro version of perl, and install pre-built CPAN modules from the distro's archives, then the install is quick, and the perl packagers from the linux distro have already sorted out and fixed dependency issues.

I am currently working on a Catalyst and Mason project using the latest version of Ubuntu as the server. I have found that I can install most of the the required libraries from the Ubuntu repositories. Where there are required libraries that are not packaged for Ubuntu, I have installed them using cpanminus, and it has worked nicely without conflicts or files getting clobbered.

I realise that this solution is practical because I am using a recent Distro where the version of perl and the perl modules are recent and reasonably complete. This would probably not be a practical proposition if I where using an infrequently updated "Long term stability" distro such as Red Hat, Debian Stable or Ubuntu LTS.

There may also be issues with the way Red Hat have packed their optional perl modules. Perhaps they are installing them in the same place as the CPAN tool does for locally built modules.

We are stuck with the Red Hat RPM for now and the foreseeable future. Installing our own perl is considered to disruptive.

Site_perl is first in @INC. When I access the CGI.pm element of the @INC hash in my test below it returns the /usr/lib/perl5/site_perl path and not the /usr/lib/perl5/5.8.8 path which also has CGI.pm.

CGI.pm exists in two locations.
# ls  /usr/lib/perl5/5.8.8/CGI.pm  /usr/lib/perl5/site_perl/5.8.8/CGI.
+pm
/usr/lib/perl5/5.8.8/CGI.pm  /usr/lib/perl5/site_perl/5.8.8/CGI.pm

Which CGI.pm are we using?
# perl -MCGI -le 'print $INC{"CGI.pm"}'
/usr/lib/perl5/site_perl/5.8.8/CGI.pm

# perl -V | tail -10
  @INC:
    /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.8
    /usr/lib/perl5/site_perl
    /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.8
    /usr/lib/perl5/vendor_perl
    /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi
    /usr/lib/perl5/5.8.8
    .
[download]

Remember, your OS vendor is only supporting perl to run it's own scripts. If it happens to also work for you, great.

TJD

Like the AM mentioned above, pretend like the system perl doesn't even exist. Its really (and I mean really) easy to make your own perl. You can even make a bunch of them (different versions, whatever you want).

The easiest way is to use something like App::perlbrew. You'll install this module with the system CPAN, and then you can install and switch between perl versions with a couple simple commands.

If you want to manage the installs yourself so you see whats going on, to me in many ways its even easier than perlbrew:

$ wget http://www.cpan.org/src/5.0/perl-5.8.1.tar.gz
$ tar -zxf perl-5.8.1.tar.gz $ cd perl-5.8.1
$ sh Configure -de -Dprefix=/opt/perl-5.8.1
$ make
$ make install
$ export PATH="/opt/perl-5.8.1/bin:$PATH"
[download]

Now you have a throwaway perl in /opt/perl-5.8.1. Say you want to upgrade your modules but roll back if it doesn't work out. With this setup you can archive /opt/perl-5.8.1, do your module upgrades and test, and if it doesn't work out just delete /opt/perl-5.8.1 and extract the archive.

See my reply at Re: Windows type needs to set up Linux with Perl 5.8.1 to match PAUSE for more summary and Re: 2nd Perl installation on Mac OSX for complete details of how I manage perl installations if you're interested.