in reply to cleaning up old libs and @INC

@INC is in the perl binary. Shocking, isn't it?

strings `which perl`|grep /usr/lib

I can tell you how I recently cleaned up my installation. I didn't have multiple perls, though, and I'm also not on Debian.

  1. I made note of which modules I have installed. cpan's autobundle feature did that. I also made a backup of perllocal.pod. These serve as a reminder of what I need to reinstall later. Obviously, I didn't reinstall everything.
  2. I cleaned up the vendor_perl directory first. I used the package manager to delete all module installed through it, making note of some dependents. I'd lose some applications that make use of those modules for the time of cleaning, but I'd reinstall the applications later. Then vendor_perl was reasonably clean, what was left I recognised as belonging to indispensible system tools, the package manager or perl itself (.ph files).
  3. I cleaned up site_perl as described in the CPAN FAQ. Those .packlist files are really useful. Sometimes I had to delete manually because of botched forced installations. The junk what was left afterwards I just moved out of the way. As it turned out, nothing of it was useful later, but better be safe than sorry.
  4. I was left with a lot of empty directories. I ran find with rmdir a couple of times do get rid of them.
  5. Lastly, I reinstalled in my package manager the perl package, so that the files in the 5.8.8 directory were guarantueed to be originals again.
(update: rmdir)
Wiki | CPAN Testers wiki

Replies are listed 'Best First'.
Re^2: cleaning up old libs and @INC
by bart (Canon) on Jul 16, 2007 at 12:12 UTC
    4. I was left with a lot of empty directories. I ran find with rmdir a couple of times do get rid of them.
    A "couple of times"??

    A pure perl solution is to use File::Find and use finddepth instead of find. That way it'll kill the deepest lieing empty directories first.

    Oh, and rmdir will not delete a directory if it's not empty.

    So you can easily recursively delete empty directories in Perl using: 

    use File::Find qw(finddepth);
finddepth sub { -d and rmdir $_ and printf STDERR "rmdir: %s\n", $File
+::Find::name }, @dirs;

    [download]
    which can probably easily be converted to a one-liner — and shortened if you don't like the verbosity: 
    finddepth sub { -d and rmdir $_ }, @dirs;

    [download]
    I haven't tried running rmdir on a plain file. Probably it's safe.
[reply]
[d/l]
[select]
      A "couple of times"??
      I felt particularly lazy there. Writing even a perl one-liner would have required more effort and documentation reading than it's worth. Running rmdir each time prunes the most nested empty dir, and I knew they would not nest deeper than 5 or 6. Much quicker.
      Oh, and rmdir will not delete a directory if it's not empty.
      I knew that. That was the point of using it.
[reply]
Re^2: cleaning up old libs and @INC
by danmcb (Monk) on Jul 16, 2007 at 03:06 UTC
    thank you! but how then is it possible for CPAN to be installing stuff where perl cannot find it?
[reply]
      how then is it possible for CPAN to be installing stuff where perl cannot find it?

      Is the "perl" that runs the Makefile.PL the same "perl" that is run when you try to use the module that CPAN has just installed ? If, for example, /usr/lib/perl runs the Makefile.PL, then the module being installed will be located in a place where /usr/lib/perl can find it, but /usr/local/lib/perl won't be able to find it.

      If it is the same "perl" in both instances, and the modules are being placed where they cannot be found, then something is seriously amiss with Config.pm's %Config.

      Cheers,
      Rob
[reply]

        that was the problem! of course. the script points to /usr/bin/perl which is the old custom built perl. I removed that and symlinked it to the system perl, now it all flies.

[reply]

In Section Seekers of Perl Wisdom