Perl on debian: confliciting perl installations on a system

Question

I updated all of the perl modules on a Debian development system (as a test) to their latest versions. I wanted to see if it was safe to upgrade the modules on the live servers. It appeared to work, except that I started getting an odd error from Imager (relating to API version numbers, however that's not really important right now).

I tried reinstalling Imager and any related libs however nothing appeared to fix the problem.

Looking further, I've found that the development system in question appears to have multiple perl directories including;

/usr/lib/perl (which contains 5.14.2 and subdirs)
/usr/lib/perl5 (which contains a range of perl modules)
/usr/local/lib/perl (which contains another 5.14.2 and a set of modules)
and even /root/perl5 (which contains a small list of modules including i486-linux-gnu-thread-multi-64int)

it appears (although I'm not entirely sure I'm reading this correctly), that modules on the system have been installed using every method possible, apt-get, aptitude, cpan, installed from source, and cpanminus and that different modules are ending up in different perl directories (I guess installations), mainly /usr/local/lib/perl or /usr/lib/perl5. I don't know how at least 2 different perl installations got on there.

I think that /usr/lib/perl is the one I want to keep, so, I tried renaming /usr/local/lib/perl to perl.save then linked /usr/local/lib/perl /usr/lib/perl. Then I reinstalled any missing packages.
Most packages seem to install however for a number I'm getting this ominous message;

---

Have /usr/local/lib/perl/5.14.2

Want /usr/lib/perl/5.14

Your perl and your Config.pm seem to have different ideas about the architecture they are running on.

Perl thinks: [5.14.2]

Config says: [i486-linux-gnu-thread-multi-64int]

This may or may not cause problems. Please check your installation of perl if you have problems building this extension.

---

After which the install of that particular module fails. Probably for good reasons.

The reason why I want to fix this is that our dev systems are all virtual, and all the other dev systems are clones of this (broken) one - so it's a problem that I need to solve hopefully without rebuilding the entire system from scratch (although his is an option).

I did try cloning the system and then purging perl, however that left me with an extremely broken system that couldn't do anything.

Any ideas for a useful approach to fixing this? Thanks

Answer 1

There are a number of "perl virtualenv" projects that make use of the "local::lib" module. This lets you install stuff for your particular application in a local directory. When used correctly these will override whatever is in the system.

This one, https://github.com/stoned/pll, uses cpanm so that you can install into your virtual environment.

This might not be what you want, but is something to consider.