CPAN itself offers no uninstall method. Several of the alternatives to CPAN do, such as CPANPLUS, or vendor port or package systems. If the module has been fully installed along with a .packlist file for the module, the ExtUtils::Packlist perl module documentation includes code for a modrm command to remove an installed module. However, note that some modules alter configuration files shared by other modules. Removing a module might cause a shared file to be altered or removed, and break other modules, causing other failures or unexpected behavior on the system. Worse, removing a module that is depended on by other modules will cause those modules to also fail.
Modules built with other tools, such as Module::Build, or those installed by hand, or any other tool that does not support the .packlist cannot be removed by ExtUtils::Packlist. Removing these modules may be difficult.
Instead Of Wasting Time Trying To Uninstall…
I never remove modules. Too much trouble, not worth the effort. The perceived need to uninstall stems from several conditions, notably testing modules—inevitable, given the numerous options the Comprehensive Perl Archive Network (CPAN) offers—or after a module has been improperly installed.
To try out new modules, use virtualization and experiment on throwaway virtual systems (or snapshot the system, and revert to the clean image when done). Or, install modules via local::lib under a test account, and cleanup the test account when done. Or even a custom install tree under your own account.
Bad installs usually result from ignoring the unit tests and force installing a module, or when a upgrade has installed an incompatible new version of a module. Do not ignore errors when building modules. Do not use the -f to cpan, as this will force install (a quite possibly broken) module onto the system. Learn what the error is, or post the full, clean build logs online for help. Use script(1) or screen to record the full build session. Incompatible modules lead back to the virtualization, test account, or test library directory methods: try out new versions on a test system. If, and only if, the new module passes all tests, installs without errors, and runs the required software properly—there are unit tests for whatever that software is, right?—then move the new module towards production use.
Convert Perl modules into a vendor ports or package system if you really think you need uninstall. These systems provide dependency checks (that help avoid leaving the system in tatters), the ability to run scripts (to properly handle that XML configuration shared between multiple modules), and more. Some even have scripts that can produce a package from a named Perl module. Consult Perl Software Depots for more ideas on how to install and manage software.
