talexb has asked for the wisdom of the Perl Monks concerning the following question:
We got some new hardware, and I'm migrating some bits of glue from one server to another. Part of this process is compiling the Perl scripts, finding out which modules aren't there and installing the missing RPMs (we're using Red Hat 9 -- that's a topic for another thread). So far, so good.
I installed Mail::Sendmail from an RPM (perl-Mail-Sendmail-0.79-1.i386.rpm), and went to confirm that Perl could now find that module so I could move on to the next missing one. It failed, and I had a look at the next missing module .. to find that Perl still couldn't find Mail::Sendmail. Hmph.
Time to refresh my memory on how all this works. Doing a perl -V on my Production machine produces
and doing the same on the new server produces@INC: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .
So I have different versions of Perl -- and paths for 5.8.0 on the older machine, and 5.8.6 down to 5.8.3 on the new machine. Interesting. And where did Mail::Sendmail end up, anyway?@INC: /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/i386-linux-thread-multi /usr/lib/perl5/5.8.6 .
Ah .. it was intalled in the 5.8.0 path. And that's not part of @INC, so the compiler complains. Now for my question./usr/lib/perl5/site_perl/5.8.0/Mail/Sendmail.pm
Should I pass an argument to rpm so that the module installs somewhere Perl can find it? Should I hack in a sym-link (I'd prefer not to move the Mail::Sendmail module by brute force)? Would newer versions of the RPM go into a higher version of the /usr/lib/perl5 tree?
There are going to be other modules I have to update, and I want to do this the right way (for some definition of right).
Thanks all.
Update Thanks for the responses .. it looks like I don't have to deal with this issue now, since this server isn't going to host this service after all. But it is good to know that sym-links wouldn't have been a horrible hack, and I knew about the PERLLIB setting as well (suitable, since this was for a cron job anyway).
Alex / talexb / Toronto
"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: @INC and using older modules with newer Perl versions
by pileofrogs (Priest) on Nov 28, 2005 at 17:41 UTC | |
|
Re: @INC and using older modules with newer Perl versions
by lRem (Scribe) on Nov 28, 2005 at 17:37 UTC |