How can I migrate a Linux Perl installation

[pete]

I have an AMD64 machine running Ubuntu 8.04 with a _lot_ of
perl modules installed. I have a need to replicate the same
set of libraries on a different box running a later version
of Ubuntu - probably 10.04 but possibly 10.10. However the
new box will be a 32-bit version, not the 64 bit system I am
running here.

Now I could settle in for a long session in front of a
perl -MCPAN -e shell prompt and pull stuff across manually.
However, this would take a long time and I would probably
miss a few modules.
I also expect that some will break, some will need hacking
and some will have been obsoleted - the original install
is a few years old.

Is there a more reliable way I could audit the modules I
have on the original box and have the same modules installed
on the new system? If it took care of dependencies, that
would be even better.

with thanks

 

[Chris Nehren]

perldoc perllocal

Except that old versions of Module::Build don't update that file, so
it's incomplete. But more-or-less yes. Try complementing it with it with
the .packlist (assuming you're not using vendor packages here, which
like to strip that file for some silly reason) files and use cpanm. The
webservice it uses is smart enough to pick out the dist a given package
belongs to, even if said package is not the same as the dist name. What
this means is that you can give it e.g. Class::MOP::Class and it'll know
you really mean Class::MOP.

.... beyond the facts that cpanm is a lot smarter than CPAN.pm and much
better at the STFU and JFDI parts.

 

[brian d foy]

I have an AMD64 machine running Ubuntu 8.04 with a _lot_ of
perl modules installed. I have a need to replicate the same
set of libraries on a different box running a later version
of Ubuntu

Part of my MyCPAN project is to figure out this problem. I've indexed
all of backpan and have fingerprints of all of the module files. I've
only just started the bits that crawl through @INC trying to match up
what it finds with files (and hence distributions) in the database.
That part of the task is only half complete, but if you're interested
in possibly using it, let me know in private email.

 

[pete]

Except that old versions of Module::Build don't update that file, so
it's incomplete. But more-or-less yes.

Thanks for that tip. I followed the earlier advice and tried perllocal,
all I got was this:
corv-root: perldoc perllocal
PERLLOCAL(1) User Contributed Perl Documentation PERLLOCAL(1)



Tue Sep 16 21:56:34 2008: "Module" Test::Harness


o "installed into: /usr/local/share/perl/5.8.8"

o "LINKTYPE: dynamic"

o "VERSION: 3.14"

o "EXE_FILES: bin/prove"

Tue Sep 16 21:56:37 2008: "Module" ExtUtils::CBuilder


o "installed into: /usr/local/share/perl/5.8.8"

o "LINKTYPE: dynamic"

o "VERSION: 0.24"

o "EXE_FILES: "



perl v5.8.8 2008-09-16 PERLLOCAL(1)
corv-root:

which made me think I was doing something wrong - from what you've told me
it looks like I didn't. For whatever reason, it only listed these 2 modules.

So far as "packlist" goes. I've never heard of this, so after a little
digging, it turns out that some modules create .packlist files when they
are installed. Running a
find / -type f -print | grep packlist shows
that I appear to have a whole slew of these in /usr/local/lib/perl
and they are lists of absolute paths to perl modules. I'll see how I can
use that information in the migration process.

 

[pete]

Odd that no one has mentioned the CPAN shell's "autobundle" command.
It will create a Bundle:: distribution that references all of your
installed modules. You copy that into ~/.cpan/Bundle/ on your target
machine, then "install Bundle::blahblah."

sherm--

Thanks Sherm, that sounds very promising. As with "there's more
than one way to do it", with Perl you can expect that pretty
much every problem has been encountered before and a solution
produced. It's just a case of finding someone sufficiently
well traveled to help you find it.