Using CPAN
This page was migrated from the old website and has not been manually reviewed, or is here for historical purposes. We make no guarantees that the content is up-to-date or reflects SIPB's current views. Contact sipb-www@mit.edu if anything is broken or you have other questions or feedback.
If you’re mostly familiar with this document, and just want the incants, skip to the cheat sheet.
CPAN is the “Comprehensive Perl Archive Network”, a repository of useful Perl modules. Most projects written in Perl depend on at least one module from CPAN, and dependency graphs of dozens of modules are not uncommon. Unfortunately, installing CPAN modules can be somewhat tricky, in part due to the age of many of the tools involved. This document is designed to help someone who is not a Perl programmer learn how to get a CPAN module or set of modules installed with a minimum of pain.
Is it in my distribution?
Most popular Linux distributions package a large number of CPAN modules as part of the distribution. If a sufficiently new version of the package you want is available from your distribution, this is likely to be a better option than installing it from CPAN.
If you are running Debian or Ubuntu, the Perl module Foo::Bar
will be present, if at all, under the name libfoo-bar-perl
. On Fedora, it will be named perl-Foo-Bar
, or can be found with the query
yum whatprovides 'perl(Foo::Bar)'
Installing packages system-wide
The easiest way to use CPAN is to install packages system-wide. Run cpan
as your user, and then enter the following commands to configure CPAN to use sudo
to get root privileges to install packages:
o conf make_install_make_command '/usr/bin/sudo /usr/bin/make'
o conf mbuild_install_build_command '/usr/bin/sudo ./Build'
o conf commit
You should now be able to install a package with install Package
.
Installing packages locally
If you don’t have root access, just want to install packages for your own use, or want to install packages into AFS for use from multiple systems, you want local::lib
. (It’s possible to configure CPAN to do this by hand, but trust me, local::lib
is easier).
-
Grab the latest
local::lib
tarball from CPAN (As of this writing, that’s version 1.008004) -
Unpack the tarball and run
perl Makefile.PL --bootstrap=/path/to/install/ make && make install
You can now run perl -I/path/to/install/lib/perl5/ -Mlocal::lib
to get a fragment of shell code you should run to set up your environment to both use perl modules from your install, and to tell cpan
to install there.
For more details, such as how to manage multiple different local::lib
installations, see local::lib
’s documentation on CPAN
Automatically installing dependencies
By default, CPAN prompts you whether or not to follow dependencies when installing a package. This is not usually what you want – if you want a specific package, you don’t care what CPAN has to install to get it to you, so it should do so automatically. There are two steps required to get CPAN to do this:
-
Within the CPAN interactive shell (run
cpan
), Setprerequisites_policy
tofollow
(o conf prerequisites_policy follow
and theno conf commit
) -
Set the environment variable
PERL_MM_USE_DEFAULT
to1
. e.g. runcpan
asenv PERL_MM_USE_DEFAULT=1 cpan
Gotchas using CPAN on Athena
- For whatever reason, perl believes itself to be smarter than your operating system by default, and checks permissions by looking at the permission bits on files, rather than using
access(2)
. (See filetest in the Perl docs.) Furthermore, when installing modules, CPAN checks to see if you have write permissions on the destination, and aborts if it doesn’t think you do, without even trying. I have been unable to find a way to override either of these behaviors.
This is a problem in AFS for obvious reasons, since AFS does not use UNIX permissions. I happen to only need to install perl modules into lockers on which I am the owner; If you need to install things somewhere where the UNIX permission bits indicate you would not have access, you’re out of luck as far as I can tell.
- Sharing a
local::lib
installation dir across multiple platforms is not recommended. While perl does include the architecture and sysname (e.g.x86_64-linux-gnu-thread-multi/
) in the path when installing.so
files for modules written in XS, it does not do the same for the version of Perl itself. So while you can share a single installation directory between 32- and 64-bit platforms, or between Linux and Solaris, all kinds of things will go wrong if you try to share it between a 32-bit perl 5.8 and a 32-bit perl 5.10 on the same platform.
I work around this for BarnOwl by having completely separate perl module installs for every AFS sysname we support. This is painful to maintain, but I’ve found it to be the most reliable option.
Cheat-sheet
Installing packages system-wide
$ env PERL_MM_USE_DEFAULT=1 cpan
# Answer 'yes' if CPAN asks to configure itself automatically
cpan> o conf make_install_make_command '/usr/bin/sudo /usr/bin/make'
cpan> o conf mbuild_install_build_command '/usr/bin/sudo ./Build'
cpan> o conf prerequisites_policy follow
cpan> o conf commit
cpan> install Some::Module
Installing packages into a directory
$ wget https://www.cpan.org/modules/by-module/lib/local-lib-1.008004.tar.gz
$ tar xzf local-lib-1.008004.tar.gz
$ cd local-lib-1.008004/
$ perl Makefile.PL --bootstrap=/install/dir/
$ make && make install
$ eval $(perl -I/install/dir/lib/perl5/ -Mlocal::lib)
$ env PERL_MM_USE_DEFAULT=1 cpan
# Answer 'yes' if CPAN asks to configure itself automatically
cpan> o conf prerequisites_policy follow
cpan> o conf commit
cpan> install Some::Module