From: Carlos Sevillano (carlos_sevillano@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
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:25:29 EDT