Welcome 216.73.216.152, local time is: 2025-10-05 08:11:09 -0700

Perl:how to uninstall perl modules

A discussion on uninstalling perl modules safely

So my question is...
How to remove the module version I installed via cpan?
I found the PPM package on cpan,
but it's got so many other dependancies.
I'm thinking there's got to be another way...

The situation differs depending on where you get your perl installation. For example, as most all of my servers run on the BSD family of Operating Systems. I end up with BSDPAN — the BSD version of CPAN. So my base perl install will be packaged with somewhat different "defaults" than that of a "vanilla" CPAN install from say, perl.org. That said, for the sake of example, I'll use the Linux family of Operating System as an example. Because it is a little easier to make analogies here.

The CPAN install layer is just a wrapper around the manual installation procedure for standard perl modules, not unlike how apt and yum are wrappers around rpm(8), and apt on debian is a wrapper around dpkg. it doesn't always play well with distributions based around binary packages (i.e. rpm(8), deb, etc...) because the two systems (CPAN and apt || yum) track dependencies differently, but it works well on "vanilla" systems, where CPAN(3) is the only tool used to manage perl(1) and its packages.

The normal (non-rpm) method of installing a perl(1) package looks something like this...

# tar -xvzf Module-1.2.3.tar.gz
# cd Module-1.2.3
# perl Makefile.PL
# make
# make test
# make install

Just about every module out there comes with an "uninstall" routine as well — I've had to manually back out perl(1) modules in the past, and as long as the original source directory hasn't been touched, "make uninstall" usually does the job well (although it knows nothing of the dependencies.)

When you're dealing with something that CPAN installed for you, you need to find where it keeps the source files, and hope that you haven't installed so many modules that the source you need has been deleted. This procedure will make CPAN tell you where it keeps the files:

# perl -MCPAN -e shell
cpan> o conf cpan_home
/usr/local/cpan
cpan> q

So in this example, /usr/local/cpan is the repository. it has a "sources" directory where the actual tarball files are kept (as well as a copy of the master lists of modules and mirrors), and a "build" directory where the compilation is done for each package. Here's an example of an uninstall:

# cd /usr/local/cpan/build
# ls
(visually "grep" the listing for the module you want to uninstall)
# cd Module-1.2.3
# make uninstall

This should work — the half dozen times i've needed to do it, it's worked out fine for me.

As an aside — for those who insist CPAN "doesn't play well with others", I've been hearing about this problem for a few years now. in fact I used to be one of them myself, until I stepped back and took an objective look at what the problem really is.

CPAN itself is a good system. It's an easy way to build automatic dependency checking into the packages, in such a way that it doesn't matter if your system is based on rpm(8) files, deb files, a certain yum or apt repository, or even that it be running on a *NIX environment. The same CPAN tarballs which would install a module on redhat linux will just as easily install the same module under debian, slackware, gentoo, lfs, BSD, windows or OSX, as long as they have the required tools on the target system — a "make(1)" tool, a working version of perl(1), possibly a C compiler, and maybe certain system libraries depending on what the module does.

The biggest problem is that people take CPAN(3) modules and re-package them as rpm(8) files. CPAN(3) and rpm(8) handle dependencies differently, which is where the problem usually shows up. Somebody will write an rpm(8) spec file which tries to say "requires perl module Blah::Blah". The only way the rpm(8) engine can tell if that module is present is for that perl module to be packaged inside of another rpm(8) and require that the user install it as an rpm(8) as well — which is why you see so many perl modules re-packaged as rpm(8).

Maybe if the rpm(8) engine had a way to correctly check whether a given perl module were present and what version it was, that would be a good thing? It's not hard, here's an example (for the Time::HiRes module.)

perl -MTime::HiRes -e 'print $Time::HiRes::VERSION'

Then if the spec file says (for example) "Requires Perl Time::HiRes", the rpm(8) engine could check whether or not it's installed, or if it says "Requires Perl Time::HiRes >= 1.35". The engine could not only make sure it's installed, but check the version number as well.

In addition, people who write software which relies on CPAN(3) modules and distribute it as an rpm(8) file shouldn't build their rpm(8) spec files to use the strict dependencies that many of them currently do. Instead of saying (for example) "Requires perl-time-hires == 1.38", they should say "Requires perl-time-hires >= 1.35". Otherwise they should be ready to release a new rpm(8) file whenever the cpan package is upgraded.

Or even better — if the software itself is written in perl(1) (which it pretty much has to be, if it requires perl modules) then they could use CPAN(3) as the distribution channel for their software, like spamassassin has done.

But writing off CPAN(3) is certainly not the answer. CPAN(3) is out there, and people use it. And as time goes on, more and more people are using it. I think if somebody makes an rpm(8) use CPAN(3) to deal with perl modules and their version numbers, this problem will go away (or at least become a lot more manageable, and less irritating to many people, than it is right now.)

Of course, everything I've said here about rpm(8) can just as easily be applied to dpkg or any other packaging format out there.

Perl:how to uninstall perl modules

A discussion on uninstalling perl modules safely

See also:

Development