Since most modules tend to follow filename/path conventions that match their given name, something like this should turn up all files/directories used by the module (including sub-modules):

find /usr/lib/perl5 -name 'ModuleName*'
[download]

May I ask why you need to do this?

I can think of a few reasons:

You:

• Find you're not using it any more and want to reclaim the disk space.

• Decide to save some money, convert from Oracle to PostGres, and no longer need DBI::Oracle.

• Accidentally find one of the lesser CPAN modules that Dominus alluded to a while back.

• Install what looks to be a great module, only to discover that it's out of date.

• (Perhaps most importantly) Install AgentM's favorite module and your wife finds out (or if you're not married, you suddenly realize why).

I'm sure there are many other possibilities.

--f

Perhaps this is just a matter of different backgrounds, but most of these reasons aren't sufficient to cause me to want to run through and remove modules from my system. I guess I see the point though.

Find you're not using it any more and want to reclaim the disk space

All 10k? Disk space is cheap. :)

Decide to save some money, convert from Oracle to PostGres, no longer need DBI::Oracle

Even working under the assumption that a migration has been 100% completed, there's still the possibility that scripts might want to interact with an Oracle database somewhere at some point of the future.

Install what looks to be a , only to discover that it's out of date.

Upgrade it. Perhaps something was lost in this sentence?

I'm not trying to rebut your points. Each of them are perfectly valid reasons I suppose for someone needing to delete a module from their system. I just don't think any of them are strong enough reasons for me to do it. At any rate, the 'find' command I noticed should suffice in locating the files used by a particular module, and assuming it doesn't break any dependencies, it's probably safe to use that to nuke them. It should also be sufficiently thorough, given the naming schemes we use for files and directories here.

Why do I want to do it? I have three systems running here:
1. a production (external) web server, with Apache, mod_perl, EmbPerl and similar stuff.
2. A production (internal) system, with a number of Perl applications and our intranet server
3. My development box
The development box now has a number of modules on it that I put on, kicked around with, and decided not to make use of. However, we try to keep all three systems in sync as far as versions, software installed and so on. I want to make sure that the development server can have stuff removed that I don't wish to run in production.

It might be easier/safer to start from a minimal installation with the stuff you want, and then pack up and distribute that filesystem to your other machines, nuking the older copies. So long as the architectures and Perl versions are the same across systems, the /usr/lib/perl5 hierarchy should be reasonably portable. That would also greatly assist your "in sync" needs.

@rem = '--*-Perl-*--
@echo off
if "%OS%" == "Windows_NT" goto WinNT
perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
goto endofperl
:WinNT
perl -x -S "%0" %*
if NOT "%COMSPEC%" == "%SystemRoot%\system32\cmd.exe" goto endofperl
if %errorlevel% == 9009 echo You do not have Perl in your PATH.
goto endofperl
@rem ';
#!perl
# dpm.pl V0.04 Dynamic Package Manager
# Copyright (c) 2000 Indy Singh/IndigoSTAR Software all rights reserve
+d



BEGIN {
    $| = 1;
    open (STDERR, ">&STDOUT");
}


use strict;
use ExtUtils::Install ();
use Config;
use File::Path; # mkpath, rmtree
[download]

<SHAMELESSPLUG>
You can check out my review here to get an idea how it(dpm) works. They even included a 'GUI'(browser) front end for it.
</SHAMELESSPLUG>

Update: on Fastolfe point,
why don't you just build the exact replica of your 'production' machine, develop 'your film' and then just switch the cable's.

"cRaZy is co01, but sometimes cRaZy is cRaZy".
                                                      - crazyinsomniac

Interesting. I've been using IndigoPerl lately too, as I've got WinNT running more often than Linux (both on the same box).

Anyway, though I haven't read the docs *thoroughly* yet (shame on me), but it appears that CPAN.pm doesn't have this ability (to remove/uninstall modules). Does anybody know why not?<?p>