SUMMARY: Perl modules question

From: Carlos Sevillano <carlos_sevillano_at_ureach.com>
Date: Tue Dec 17 2002 - 12:28:23 EST
The general consensus was to re-install the
Perl modules.   Thanks to all who replied:

Karl Vogel" <vogelke@dnaco.net>
Fabrice Guerini <fabrice@life.net>
"Doug Hubbard" <doug@trackmaster.com> 
Hindley Nick <nick.hindley@lbhf.gov.uk>
lupe@lupe-christoph.de (Lupe Christoph)
Glenn Harrison <glennharrison@amcorp.com.au>
"Thomas M. Payerle"
<payerle@physics.umd.edu>
Yura Pismerov <ypismerov@tucows.com>
Larye Parkins <LParkins@niaid.nih.gov>
"Vandevegt, James Matthew (Jim)"
<vandevegt@avaya.com>



Karl Vogel" <vogelke@dnaco.net>
    http://cpan.org/misc/cpan-faq.html
    How do I install Perl modules?

    Installing a new module can be as simple
as typing
      perl -MCPAN -e 'install
Chocolate::Belgian'

   
http://search.cpan.org/author/JHI/perl-5.8.0/lib/CPAN.pm
    The CPAN.pm documentation has more
complete instructions on how to use
    this convenient tool.  If you are
uncomfortable with having something
    take that much control over your
software installation, or it otherwise
    doesn't work for you, the perlmodinstall
documentation covers module
    installation for UNIX, Windows and
Macintosh in more familiar terms.
    
    
Fabrice Guerini <fabrice@life.net>
 If I were you, I'd just reinstall them.
It's easy. Run

          # perl -MCPAN -e 'shell'

 and type

          install Net::Ping
          install Net::Telnet::Cisco
          install Net::FTP
          install Tie::SecureHash
          install Proc::ProcessTable
          install Date::Calc
          install Data::Dumper

 >One more question... how does perl know
 >where these modules are located.?  I know
 >how perl is calling them Use Net::Dumper. 
I
 >am not sure how perl knows that the
 >Data:Dumper module is in any of the four
 >paths mentioned below?

 Just like your shell uses the $PATH
environment variable to determine which 
 "ls" command to exec, Perl uses the @INC
array to search for modules and 
 packages.    


 "Doug Hubbard" <doug@trackmaster.com> 
 My advice would be to download the latest
packages from CPAN 
 and reinstall them cleanly. It is during
the make install OF THE 
 PACKAGE that the @INC array is updated for
perl so it knows that 
 the package is installed.

 There may also have been bug fixes since
the packages were 
 installed on the previous machine. All in
all I prefer to just reinstall 
 the packages and know I have a clean solid
setup (especially since 
 you said this is a new box, why inherit any
quirks that may be on 
 the old one)


Hindley Nick <nick.hindley@lbhf.gov.uk>
If I were you I'd download and reinstall the
modules:

 i. bugs are fixed all the time and its
often better to get the latest
 versions

 ii. the perl modules tend to have a good
idea of what the original
 configuration of perl was when they were
installed.  Its often difficult to
 reproduce the exact configuration 



lupe@lupe-christoph.de (Lupe Christoph)
...
...
 > Can I just copy everything by hand
 > from the old machine?

 No you can't. You could never be sure if
something was branded with a
 5.005_03-ism. Besides, this is the
opportunity to update. Some Perl
 modules had security patches in the past.

 > I am not sure why,
 > however, some of them are on multiple
 > locations on the old machine:

 >       old system:
 >       Tie::SecureHash;  = SecureHash.pm

 >
/usr/local/bin/Tie-SecureHash-1.03/SecureHash.pm

 This is not a normal Perl library
directory. What do the @INC's in
 5.005_03 and in 5.6.1 show?

 >
/usr/local/bin/Tie-SecureHash-1.03/blib/lib/Tie/SecureHash.pm

 blib is a directory that gets created when
a module is built. It should
 never appear in the installation
directories. Search and destroy all
 blibs. /usr/local/bin was misused as a
build directory - destroy all
 subdirectories there that contain
Makefile.PL's.

 >
/usr/local/lib/perl5/site_perl/5.6.0/Tie/SecureHash.pm

 This looks like the real thing. But didn't
you say 5.6.1?

 > One more question... how does perl know
 > where these modules are located.?  I know
 > how perl is calling them Use
Net::Dumper.  I
 > am not sure how perl knows that the
 > Data:Dumper module is in any of the four
 > paths mentioned below? 

 It looks in the directories in @INC (you
see it with perl -V) for
 Data/Dumper.pm.

 > Is that information built into perl when
you
 > compile the module using "perl
Makefile.PL;
 > make, make test; and make install"?

 No, make install just puts the module files
in places where Perl will
 find them. There are different places for
modules that contain C code,
 etc. Perl autoloading is quite
sophaisticated.


Glenn Harrison <glennharrison@amcorp.com.au>
I'd download all the module sources and
compile them in properly again.  Make sure
you get the correct versions though, as
 some modules change syntax and
functionality as they move up version
numbers.


"Thomas M. Payerle"
<payerle@physics.umd.edu>
Your best bet is to reinstall/remake from
CPAN sources.  This will also 
 probably get you new and hopefully improved
versions.  Alternatively, if
 you still have the original sources, you
can try reinstalling with that,
 but the more up-to-date sources are
probably better.
 
 
Yura Pismerov <ypismerov@tucows.com>
You will have to reinstall all the modules.
 

 Larye Parkins <LParkins@niaid.nih.gov>
or the least hassle, download the source
packages from CPAN and make and install them
separately: if you use the CPAN
 module, it will try to upgrade you to the
latest Perl distribution, which is hours of
work and confusing if it completes at all.

 When Perl is compiled, it knows where its
modules are kept.  It is not uncommon to
have Perl 5.005xx, Perl 5.6.1, and Perl 5.8
on
 the same system, or multiple instances of
the same Perl version with different sets of
modules.  Many web-based applications
 come with their own version of Apache and
Perl, for instance.

 You can also use the -I option in the
shebang line to point to other module
directories if you have special modules only
used by
 certain scripts.  You might use -I to test
whether the old 5.005 modules will work with
Perl 5.6.1 before you start building new
 ones, especially if you have custom
modules.

 -- 


"Vandevegt, James Matthew (Jim)"
<vandevegt@avaya.com> 
Definitely use the CPAN module to download
and install the modules. It takes care of
installing any
dependencies and you get the latest versions
of everything.

It also ensures correct compiler and flags
are used -- the same ones that compiled
perl.



ORIGINAL POSTING:
Carlos Sevillano
<carlos_sevillano@ureach.com>

Solaris 2.6
 Perl 5005.03/5.60 
 to 
 Perl 5.6.1

 I have an old system running perl 5005.03. 
 At some point someone updated perl, just
the
 perl binaries and libraries to Perl 5.60 
 (perl -v shows 5.60 - Pkginfo shows perl
 5005.03).  I am building a new system and
 need to migrate what they have perl-wise 
to
 the new system running Perl 5.6.1.  

 The problem is that I ran into a buch of
 modules that were available under 5005.03
 that I have to update on the new
 installation.  These modules work with the
 Perl DBI and Perl DBD and many custom perl
 modules to act as an "application".  

 What is the right way to migrate all these
 modules?  Do I have to collect them from
the
 CPAN and do a a native install ... can they
 be copied from the old system to the new
 one?  Here are the modules in question:

         Net::Ping;
         Net::Telnet::Cisco;
         Net::FTP;
         Tie::SecureHash;
         Proc::ProcessTable;
         Date::Calc;
         Data::Dumper;

 The modules are not part of the standard
 Perl distribution, they are not available
on
 the clean perl installation (some of them
 like Tie are, however, the SecureHash part
 is not).  Can I just copy everything by
hand
 from the old machine?  I am not sure why,
 however, some of them are on multiple
 locations on the old machine:

         old system:
         Tie::SecureHash;  = SecureHash.pm


/usr/local/bin/Tie-SecureHash-1.03/SecureHash.pm


/usr/local/bin/Tie-SecureHash-1.03/blib/lib/Tie/SecureHash.pm


/usr/local/lib/perl5/site_perl/5.6.0/Tie/SecureHash.pm

         Net::Ping; = Ping.pm
        
/usr/local/bin/perl-5.6.0/lib/Net/Ping.pm
        
/usr/local/lib/perl5/5.00503/Net/Ping.pm
        
/usr/local/lib/perl5/5.6.0/Net/Ping.pm

         Net::Telnet::Cisco; = Telnet.pm


/usr/local/bin/Net-Telnet-3.02/lib/Net/Telnet.pm


/usr/local/bin/Net-Telnet-3.02/blib/lib/Net/Telnet.pm


/usr/local/lib/perl5/site_perl/5.6.0/Net/Telnet.pm

         Net::FTP; = FTP.pm
        
/usr/local/bin/libnet-1.0703/Net/FTP.pm


/usr/local/bin/libnet-1.0703/blib/lib/Net/FTP.pm


/usr/local/lib/perl5/site_perl/5.6.0/Net/FTP.pm

         Proc::ProcessTable; =
ProcessTable.pm


/usr/local/bin/Proc-ProcessTable-0.27/ProcessTable.pm


/usr/local/bin/Proc-ProcessTable-0.27/blib/lib/Proc/ProcessTable.pm


/usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/Proc/ProcessTable.pm

         Date::Calc; = Calc.pm
        
/usr/local/bin/Date-Calc-4.3/Calc.pm


/usr/local/bin/Date-Calc-4.3/blib/lib/Date/Calc.pm


/usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/Date/Calc.pm

         Data::Dumper; = Dumper.pm


/usr/local/bin/perl-5.6.0/ext/Data/Dumper/Dumper.pm


/usr/local/bin/perl-5.6.0/lib/Data/Dumper.pm
        
/usr/local/lib/perl5/5.00503/Data/Dumper.pm


/usr/local/lib/perl5/5.6.0/sun4-solaris/Data/Dumper.pm

 One more question... how does perl know
 where these modules are located.?  I know
 how perl is calling them Use Net::Dumper. 
I
 am not sure how perl knows that the
 Data:Dumper module is in any of the four
 paths mentioned below? 

         Data::Dumper; = Dumper.pm


/usr/local/bin/perl-5.6.0/ext/Data/Dumper/Dumper.pm


/usr/local/bin/perl-5.6.0/lib/Data/Dumper.pm
        
/usr/local/lib/perl5/5.00503/Data/Dumper.pm


/usr/local/lib/perl5/5.6.0/sun4-solaris/Data/Dumper.pm

 Is that information built into perl when
you
 compile the module using "perl Makefile.PL;
 make, make test; and make install"?

 Carlos


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Tue Dec 17 12:31:32 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:00 EST