Anonymous Monk:

I've seen two common cases that give the symptoms you describe:

1. There could be multiple versions of perl on your system. So when you log in as root and install modules from cpan, it affects the version of perl used by the root account.
   Note: If your operating system provides Perl, it's often because some of the operating system utilities use perl. So there's an operational risk in upgrading the system perl or installing/upgrading modules. Similarly, if your application is using perl, you don't want an operating system upgrade to cause you a problem by changing your perl under you (possibly exposing you to a new bug) or changing a module version. That's why we advise people to leave the system perl alone and install a different perl for your application and/or local use.
2. The other common case is that some of the directories in your @INC path have restrictive permissions. So while the root account can access the directories to install the module(s), other accounts (such as the account your webserver is running under) don't have access, so they won't be able to find the module(s).

Some people will compile a new perl from source manually, or use a tool like perlbrew to automate the process. I use perlbrew because it makes managing multiple versions of perl on my box simple. That way, my development box has all the versions of perl any of the production servers use.

Since production changes have to go through testing and review processes, not all servers always run the same version of perl. So to fix a problem for a particular server, I can tell perlbrew to switch to a particular version, check out the application code and get to work. Or if I want to upgrade perl on a server, I can tell perlbrew to install the new version and run the application through its paces on my dev box to see if there are any problem areas.

...roboticus

When your only tool is a hammer, all problems look like your thumb.