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

@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 .
and doing the same on the new server produces
@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 .
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?
/usr/lib/perl5/site_perl/5.8.0/Mail/Sendmail.pm
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.

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

    Ok, that's wierd. It looks like you've installed perl and Mail::Sendmail from different systems/versions/distributions. If you installed Perl from RPM and Mail::Sendmail from RPM, then they should agree on what directories are a good place to install stuff.

    Since you're using an outdated OS, chances are you can't use CPAN without basically re-installing perl. (CPAN will want to update perl itself if it's old.)

    If I were in your shoes, and I couldn't upgrade to Fedora Core 4, I'd re-install the entire perl system via CPAN, including all the extras like Mail::Sendmail. Then I'd delete the old one and create sym-links where required so as to make the new one take the place of the old one.

    You'll want to make a list of modules you had on the old system. Autobundle can help with that, but I'm not very familliar with it. (Do a search here on perlmonks.)

    -Pileofrogs

Re: @INC and using older modules with newer Perl versions
by lRem (Scribe) on Nov 28, 2005 at 17:37 UTC
    You probably can move/symlink the modules into the new directory without problems. You can also try setting the PERLLIB or PERL5LIB environment variables, to make perl aware of the old directory. Or, most effective, you can recompile perl to use that directory by default.
    --
    Someday, people who know how to use computers will rule over those who don't. And there will be a special name for them: secretaries. -Dilbert quote