in reply to Re^4: TT2 and FB between two different installations
in thread TT2 and FB between two different installations

Ah, my mistake, I thought that a native perl would not look under /usr/local/ for modules, so your errno problems seemed to indicate a custom perl install. If I do perl -V on my SuSe, there are no /usr/local/... paths in @INC.

Generally it is not advisable to mix OS updates and CPAN with core modules or those installed by a minimal debian install (since some of them get patched by debian). If the module was not already installed by debian, a cpan install is harmless

When you use CPAN, make sure it doesn't overwrite OS perl modules (that should normally be the case, as OS perl modules should reside in /usr/lib or /usr/share and cpan defaults to /usr/local AFAIK. Don't change that, then you are pretty safe).

But since you have updated core modules with cpan, one alternative would be just to try to live with it. Most of the time you should have no problems with that. Errno.pm is more the exception than the rule

The other alternative is as I said in my first post, just delete the stuff under /usr/local/share/perl and edit perllocal.pod accordingly. That should effectively rid you of your cpan-installed modules.

This is because your debian perl modules were not overwritten by cpan. The cpan modules have just a higher priority and so mask the original debian modules that are stored under /usr/share/

You can test this by installing a small perl module with apt-get and look where it was stored. Then install a newer version of the module with cpan and look where that was stored. Both versions should be on your disk, just in different dirs. Patch one with a print statement and find out which is used by a simple script (presumably the cpan version). Now delete that version (by deleting the <modulename>.pm) and the old version should be used again.

Another indication that this is true was your deletion of (cpan) Errno.pm. After that the install of cpio worked so perl must have found the original Errno.pm from debian.

So if you remove the cpan modules completely (or rename the dirs under /usr/share/perl/) you should have your native perl back. And then (after editing perllocal.pod? Don't know if this file is used by cpan) you can install cpan modules again, just make sure you don't touch system modules. CGI for example should be quite safe to install with cpan

PS: You asked about a dual perl installation in your first posting. That is easy if those perls differ in version (because one looks under /.../5.8.8/ for its modules, the other under /.../5.10/ for example) but with two perls of the same version you have to do much more. That's why I was talking about perl5.10. It just makes it easy to keep debian perl and cpan perl apart.

UPDATE: A fast way to check that none of the files in /usr/local/share/perl were installed by debians package manager: 

find /usr/local/share/perl -print | xargs dpkg -S | less

[download]
dpkg -S tells you from which package a file is. Check the list. If none of the files are from a package, debian doesn't store any files there.

By doing the same with /usr/share/perl and looking for non-package files you can find out if cpan has installed anything in debians area.

Replies are listed 'Best First'.
Re^6: TT2 and FB between two different installations
by LesleyB (Friar) on Jul 22, 2008 at 11:37 UTC

    Thank you very much for this info.

    I used to use SuSE and it kept far more up-to-date than Debian stable does but then I could go to the bleeding edge and live with unstable/testing if I wanted to.

    The original plan was to keep the perls on the two machines in step but this has failed somehow. FWIW the @INC on my local machine is at @INC is /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . Anything in the /usr/local dirs supersedes that in the /usr/share or /usr/lib.

    I found entries in /usr/local/share/perl/5.8.8 including CGI v3.35 on the remote machine so at some point in the past I had attempted to upgrade the remote to match the local on CGI. I have been brutal with the remote machine and did an apt-get remove perl. Luckily the machine held up to that treatment but this action removed a lot of stuff including mysql, spamassassin and ntp. It was interesting for me at least, to note what was left in /usr/share/perl* and /usr/lib/perl* after that treatment. e.g.

    l /usr/lib/perl/5.8.8/
total 108
drwxr-xr-x 10 root root  4096 2008-07-22 11:09 auto
drwxr-xr-x  2 root root  4096 2008-07-22 11:09 B
-rw-r--r--  1 root root  7288 2008-04-25 21:45 B.pm
-rw-r--r--  1 root root  2570 2008-04-25 21:45 Config.pm
-rw-r--r--  1 root root 13691 2008-04-25 21:45 Cwd.pm
-rw-r--r--  1 root root  8884 2008-04-25 21:45 DynaLoader.pm
-rw-r--r--  1 root root  5967 2008-04-25 21:45 Errno.pm
-rw-r--r--  1 root root  3458 2008-04-25 21:45 Fcntl.pm
drwxr-xr-x  2 root root  4096 2008-05-04 13:58 File
drwxr-xr-x  3 root root  4096 2008-07-22 11:09 IO
-rw-r--r--  1 root root   413 2008-04-25 21:45 IO.pm
-rw-r--r--  1 root root  3111 2008-04-25 21:45 lib.pm
drwxr-xr-x  2 root root  4096 2008-05-04 13:58 List
-rw-------  1 root root  6416 2008-04-05 19:22 perllocal.pod
-rw-r--r--  1 root root  1435 2008-04-25 21:45 POSIX.pm
-rw-r--r--  1 root root  1340 2008-04-25 21:45 re.pm
drwxr-xr-x  2 root root  4096 2008-05-04 13:58 Scalar
-rw-r--r--  1 root root  3514 2008-04-25 21:45 Socket.pm
-rw-r--r--  1 root root  3408 2008-04-25 21:45 XSLoader.pm

    [download]
    I then removed everything in /usr/local/share/perl/5.8.8 and reinstalled perl and the modules I needed to get hopefully somewhere back to a straight playing field. I think that puts the remote back in a standard platform state.

    Doing the same on the local machine will scrub out KDE and X server so I will try checking what belongs in /usr/local/share/perl as you suggest first and see what I can fix that way.

    Thank you for your help.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom