in reply to Removing Modules

Are you talking about deleting a module from your system? I don't know that I've ever heard anyone ask that.

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]
If that looks kosher, appending an -exec rm -rf {} \; to that should do the trick, provided you understand what it does and trust the 'find' output.

May I ask why you need to do this?

Replies are listed 'Best First'.
Re: Re: Removing Modules
by footpad (Abbot) on Feb 02, 2001 at 08:23 UTC
    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
[reply]
      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.
[reply]
Re: Re: Removing Modules
by Maclir (Curate) on Feb 02, 2001 at 08:16 UTC
    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.
[reply]
      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.
[reply]
        You'll need the corresponding Perl binaries, if there's any chance anything was built differently between machines. Here's my script for building a tar-gzip file that I use to update the sites I keep in sync: 
        cd /usr/local/
find lib/perl5 -name "*.a" -o -name "*.html" > /tmp/nocopy
gtar zcvf /tmp/Perl5.tar.gz lib/perl5 -X /tmp/nocopy bin/perl* bin/pod
+* lib/libperl*
rm -f /tmp/nocopy

        [download]
        This avoids copying the library and HTML doc files that aren't needed at the other sites.
[reply]
[d/l]

In Section Seekers of Perl Wisdom