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

Isn't Errno.pm a core module? Then why do you have it in /usr/local/share?

The only reason to account for that situation that I can think of is that you installed a new perl version in /usr/local and the system is using this new perl now.

In that case it might help to rename the newer perl to perl5.8.8 (or delete it, since it probably is an alias to perl5.8.8 anyway). Let the system use and update its old perl. In your homedirs ~/bin you can put an alias to perl5.8.8. Provided that your home bin is first in your PATH your non-root scripts will then use the newer perl.

IMPORTANT: The only script that you must call as root with perl5.8.8 instead of the system perl is cpan (if you want the perl modules in /usr/local and not in your homedir). You might even patch the cpan script with 'use 5.8.8' so that you don't forget it.

This should probably also help your cpio upgrade getting through.

This is also the method I would employ on your remote machine. Install a newer perl in /usr/local and make sure through renaming that root and the system doesn't use it. Let the system care for the system perl, only your web scripts (in other words the web server) and the cpan script should use the newer perl.

  • Comment on Re^3: TT2 and FB between two different installations

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

    Well, I went into CPAN and found that I could list all the modules that needed updating so I ran through lots of those. A lot got installed in /usr/local/share/perl/5.8.8.

    I just checked my perl version 

    lesleyb@fawcett:~$ /usr/bin/perl -v

This is perl, v5.8.8 built for i486-linux-gnu-thread-multi

Copyright 1987-2006, Larry Wall

Perl may be copied only under the terms of either the Artistic License
+ or the
GNU General Public License, which may be found in the Perl 5 source ki
+t.

Complete documentation for Perl, including FAQ lists, should be found 
+on
this system using "man perl" or "perldoc perl".  If you have access to
+ the
Internet, point your browser at http://www.perl.org/, the Perl Home Pa
+ge.

    [download]

    I have no idea where this newer version of perl might be hiding but I am not picking it up in mormal operations. Or at least what is normal for me ;)

    I fixed the cpio upgrade problem by removing Errno.pm and keeping my fingers crossed (and eyes wide shut). The upgrade then worked. What worries me is I have no idea what else is lurking in /usr/local/share/perl/5.8.8 that might come up and bite me later on.

    It's not a question of wanting 5.10 on board at the moment. In fact I want the opposite. I would like to keep both the local and remote machine in step and I'm happy to stay on 5.8.8. All I really want to do is upgrade some modules to the latest for my version of perl.

    As an example, CGI.pm is two years out of date on Debian stable. The version on Debian stable contains a minor bug which irritates me. I would like to produce to the charset I want or the project requires.

    Anyway, at the moment I'm restricting my development to the remote machine so that I develop with what I actually have available on a standard install.

    I'm begining to think I need to reinstall perl completely on the local machine just to get back to a known state and I'll have to ask in the appropriate quarters about the feasibility of that. For instance, I have no idea whether the non-existence of perl would break anything in apt-get or aptitude. It would kind of stuff things if it did!

[reply]
[d/l]
      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.

[reply]
[d/l]

        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