Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

cleaning up old libs and @INC

by danmcb (Monk)
on Jul 15, 2007 at 22:31 UTC ( [id://626745]=perlquestion: print w/replies, xml ) Need Help??

danmcb has asked for the wisdom of the Perl Monks concerning the following question:

hi

I have a debian box that I have run for about 3 years now. Innumerable modules and perls have run on it (including for a while one I built from scratch to use with apache, and foolishly wrote over the system perl) ...

I see now that @INC is kind of a mess, lots and lots of lib paths, including some to 5.8.7 that probably need to be cleaned.

I also have a problem that I install a module (encoding::warnings) with CPAN, and yet it puts it somewhere where the system perl can't find it. (its a matter of a /usr/local/lib/perl5/ ... where @INC only has /usr/local/lib/perl/ ... )

so it's all foobar.

How can I :

1: get CPAN and perl back in sync (they are both recent installs via apt/CPAN from the last few days)

2: keep only what *should* be in @INC, and remove refs to obsolete perls (allowing me to merrily delete the old libs?)

thanks!! I have searched, I have sought ... but clear instructions have I found on how CPAN decides where to put libraries, and how perl gets @INC, which is obviously rather related ....

Replies are listed 'Best First'.
Re: cleaning up old libs and @INC
by daxim (Curate) on Jul 15, 2007 at 23:44 UTC

    @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)
      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;
      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;
      I haven't tried running rmdir on a plain file. Probably it's safe.
        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.
      thank you! but how then is it possible for CPAN to be installing stuff where perl cannot find it?
        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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://626745]
Approved by naikonta
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (5)
As of 2024-04-25 10:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found