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.