Re: Automating CPAN Configuration

Don't :)

1) use a package manager instead of -MCPAN. IE, if you're on a debian system and you want to install DBI and the mysql drivers, do

 apt-get -y install libdbd-mysql-perl libdbi-perl

Easy to automate across your 100 machines.

This assumes someone (perhaps yourself) has already created packages of these modules.

2) create a directory structure for your perl modules. (IE /organization/opt/perl-modules/.) On a master machine (build box), install your modules into this hierarchy. Then rsync the 'perl-modules' directory structure to the 100 boxes.

CPAN as an archive is awesome. -MCPAN as a method for software installation .. not so much. It was cool when I discovered it back in the day, but now I really really really wish that CPAN defined a standard 'perl module package format' -- a single archive file containing the module, and a package manager tool to add/list/remove packages. Failing that, it would be cute if CPAN would automagically create .debs, .rpms, or Solaris pkgs.

Comment on Re: Automating CPAN Configuration

Replies are listed 'Best First'.
Re^2: Automating CPAN Configuration by adamk (Chaplain) on May 12, 2006 at 02:37 UTC
Agreed on the package manager thing. _If_ your package manager supports all the modules you need, with all the versions you need, then you should be using that. Unfortunately, the number of CPAN modules is higher than the total package count for several distributions, so that isn't always (often?) possible.	[reply]
Re^2: Automating CPAN Configuration by dsheroh (Monsignor) on May 12, 2006 at 15:15 UTC
Don't Don't use CPAN? What heresy is this? Where's the real monastery and how did this impostor manage to take its place? Personally, at home, I do prefer to use Debian's package repository to install modules rather than going to CPAN for them. In the current case, though, I'm working with a client whose change management policy makes it cumbersome to install packages from the OS vendor, but CPAN flies under its radar, so that's the admin team's preference. Also, the current *nix environment is a mix of Red Hat and HP-UX, with an influx of Solaris looking likely in the mid-term future; although RH seems likely to have several modules packaged, I'm not so sure that I'd expect the same from HP and Sun. This mixed environment would also obviously complicate any attempt at setting up a (set of) master build box(es) unless it's restricted to only pure-Perl modules. CPAN may not be the best solution (doing a separate `make` on each host is inefficient, if nothing else), but it works well enough.	[reply] [d/l]