Avoid using the system Perl if you can. Have your users/applications use a local installation of Perl. This prevents Perl module conflicts with what RHEL is expecting. It also has the benefit of when you upgrade to the new version of RHEL (or migrate to another machine), you can just tar ball the Perl directory and extract.

Note that “tarballs” can be expected to work across machines only if the surrounding environment ... installed libraries and library-versions ... are known to be identical across the machines.   Many CPAN modules install themselves by compiling C programs, checking installed library versions, and other magickal things.   Then, they run a slew of self-tests to make certain everything works.   Everything should be copacetic if, say, the machines are known to be “corporate clones” of one another.

What most-certainly won’t work is a migration from AIX to (Red Hat or otherwise) Linux.   Apples and oranges.   The binary modules upon which many Perl libraries actually depend will not load or run correctly.   You must repeat the install on one Red Hat machine ... letting CPAN discover and compile and link and otherwise do whatever it takes to accommodate Linux.   Then, perhaps, you can tarball-clone that.   When the dust finally settles, the Perl programs should then run more-or-less identically.

I thought that was obvious but you are correct that I should have explicitly stated that. :)

Jason L. Froebe

Blog, Tech Blog

Thanks! Can I use the perllocal.mod on machine1 to clone the installed modules on machine2? If yes, how, are there any scripts that parse the content and make the installation?

I thought of using CPAN or a simple script like instmodsh (from ExtUtils::Installed) to get the list of your modules, and then mangle the names to find the rpm's.

perldoc ExtUtils::Installed

I found the option to consider the modules in a given directory my $installed = ExtUtils::Installed->new(extra_libs=>["/my/lib/path"]); But I still don't understand why is there a huge difference in the number of modules found by this method and by using find *.pm? There are more than 10x more .pm files as modules found by this method. Can multiple .pm files belong to a module?

I found it out: it seem a module can contain several .pm files.

I have been working on a solutions that is based on the find *.pm and yum whatprovides, but it needs a lot of parsing of the yum output in order to create a list of rpms and repositories that need to be installed on the new RH machines. Thanks for the tip with the Extutils:Installed. Unfortunatelly, listing the installed modules using instmodsh only shows a tiny fraction of all the installed modules, probably because they are installed outside the default directories.

Thanks, as I understand this tool is for packaging a given Perl application. Is it also possible with this tool to package the whole Perl/CPAN environment on AIX and migrate it to RedHat? I would prefer a cleaner process based on original rpm packages, which makes it simpler to replicate the same environment on a high number of servers.

Last time it happed was just a few days ago when I tried to install HTML::Mason and Apache::Request was missing. The official repo had no RPM for my platform and so I had to install about 25-30 modules from CPAN anyway. The RPM'ed HTML::Mason ofcourse refused to work with those, so I had to reinstall that from CPAN as well.

Long story short: Just bite the compile bullet and install from CPAN right away, because that's what you'll end up doing anyway.

Just my 0.02€

Thanks FloydATC, If I would like to replicate the CPAN from one machine to the other, what should I do? Should I use the perllocal.doc file from machine1 with some parser to install the same modules on machine2? I guess the autobundle wont work if the two machines are different architectures (AIX vs. RedHat on x86).

I found a comprehensive solution for the problem here: http://www.ibm.com/developerworks/linux/library/l-depperl/index.html