Using Perl Modules from CPAN with Distribution Packaged Modules

When I first started using CPAN, this was a concern of mine that I was never able to fully address: how do Perl modules from CPAN interact with modules installed via distribution packages?

It turns out that the answer is simple. First, however, let’s install a set of tools called pmtools; these tools will tell you a lot and make it simple. Using these will help you to understand how your system is set up as well. In Ubuntu, the package is called pmtools; in Red Hat, it is perl-pmtools. To install, use this command on an Ubuntu system as root:

$ sudo apt-get install pmtools

On a Red Hat Enterprise Linux system, use this command instead:

$ sudo yum install perl-pmtools

Once that is installed, use the tool pmdirs to see what directories are searched for modules in order. Here is one example from an Ubuntu 10.04 LTS server system:

$ pmdirs
/etc/perl
/usr/local/lib/perl/5.10.1
/usr/local/share/perl/5.10.1
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.10
/usr/share/perl/5.10
/usr/local/lib/site_perl
.

With this, you can see that several site-specific directories in /usr/local are searched before system directories in /usr.

Same thing holds true for Red Hat; here is an example from a Red Hat Enterprise Linux 5.7 system:

$ pmdirs
/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
.

In Red Hat, system-installed Perl modules go into /usr/lib/perl5/vendorperl/$version/ while modules installed with CPAN go into /usr/lib/perl5/siteperl/$version/. On the other hand, in Ubuntu, CPAN modules go into /usr/local/share/perl5/$version/ while packaged modules are placed in /usr/lib/perl/$version/.

This means that modules installed with CPAN will be searched (and found) first – whether they are newer or not. Usually they will be newer, but if they are the same version you’re better off staying with the packaged version of the Perl module as it will often have bugfixes and patches not present on the original.

If you want to see where a particular module lives – use pmpath:

$ pmpath CPAN
/usr/local/share/perl/5.10.1/CPAN.pm

This shows that CPAN was installed from (or updated from) CPAN as well.

If you want to see what version is installed, use pmvers:

$ pmvers CPAN
1.9600

Note: In Ubuntu you may find that the directory /usr/local/lib/site_perl is missing and that some pmtools utilities will fail because of this. Use this command to create the directory (and stop the error messages):

# mkdir -p /usr/local/lib/site_perl

Installing VMware vSphere CLI 4.0 in Ubuntu 10.04 LTS

Installing the VMware vSphere Command Line Interface (CLI) has the potential for problems. In my case, it generated an error – a three-year old error. Perl returns the error:

undefined symbol: Perl_Tstack_sp_ptr

Not only has this error been around for three years, it also has shown up in numerous other instances. Ed Haletky wrestled with the error in VMware vSphere CLI back in June of 2008. The error surfaced in Arch Linux in 2008, both in running their package manager and in running cpan itself. This error also came up (again in 2008) in attempting to build and run Zimbra. (The response from Zimbra support was cold and unwavering: we don’t support that environment and won’t discuss it. How unfortunate.) The error also affected the installation of Bugzilla according to this email thread from 2009.

On the Perl Porters mailing list, there is an in-depth response as to what causes this error. From reading these messages, it appears that there are two related causes:

• Using modules compiled for Perl 5.8 with Perl 5.10
• Using modules compiled against a threaded Perl with an unthreaded Perl

One recommended solution is to recompile the modules using the cpan utility:

cpan -r

That may or may not be enough; it depends on if there were other errors. In attempting to run the vSphere CLI, I get this error:

IO::Compress::Gzip version 2.02 required--this is only version 2.005

To fix this, I ran cpan this way:

cpan IO::Compress::Gzip

In my case, that loaded IO::Compress::Gzip version 2.033.

I also loaded the libxml2-dev package; I don’t know if that was necessary or not:

apt-get install libxml2-dev

Whenever using cpan, I always wonder how it affects my packaged installations and whether it installs for all users or just me (and how to control that) – but I’ve never had any problems and installs as root seem to go into /usr/local – which makes sense.

Having done all this, I can now use the vSphere CLI to activate SNMP on the ESXi 4 servers. For the record, this is an integral part of ESXi 4 and supports all SNMP polling and traps – previously, only SNMP traps were supported. Certainly a nice improvement.