use Perl

• Mounting? (Score:1)

  by clscott (4354)

  Use whatever network files services your OS enables (like NFS,SMB).
  Then one server can be the master and the others can mount them.
• syncing CPAN modules (Score:1)

  by jbisbee (2452)

  Right now we migrate code via CVS export and rsync by using cvs rtag TAG MODULE1 MODULE2. and then using psync (a perl wrapper around rsync that has a config file to do multiple rsyncs).

  Anyway, I recently was battling this exact same problem when upgrading DBI and DBD::Sybase on our servers and I wanted to changes to go with the migration (I also wanted a way to roll back in case all HELL broke loose)

  My solution was to make a new CVS module called CPAN and then install the CPAN modules into that direct

  --
  

  -biz-
  • Re:syncing CPAN modules (Score:2)

    by hfb (74)

    Have you tried using CPAN::Site?
• try reading the CPAN FAQ :) (Score:2)

  by hfb (74)

  You could either use a Bundle or Autobundle which are slightly different since Autobundle will make a bundle of everything, including the core modules. Both of these are mentioned in reasonable detail on the FAQ. You can also use ExtUtils::Installed to generate a list of installed modules [ also in the FAQ ] on all the boxes, compare them, and then either generate a Bundle or use CPAN.pm to install. You can also use "perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)'" to update everything automati
  • Re:try reading the CPAN FAQ :) (Score:2)

    by gav (2710)

    Thanks for the tip. ExtUtils::Installed works beautifully. I think the trick will be to create bundles and push them to the other servers, the only problem seems to be modules that have interactive installers.
• Fotango::Build (Score:1)

  by james (1129)

  We have the same issue at Fotango. Essentially we've come to the decision that if something is used by our source, then we need to version control it. The net result has been doing vendor imports of huge amounts of source code (ie, apache, mod_perl, perl, all CPAN modules, etc) into our version control system.
  
  We are also putting together a build system so that our systems all build into one app directory with its own bin, lib and include dirs.
  
  The individual package build instructions live on our intrane
• Another option ... (Score:1)

  by rob_au (1845)

  Another option which may be worth investigating depending upon the network environment would be the use of PAR archives.

  The latest version of PAR (0.74) is fairly stable and incorporates the facility to specify PAR archives by remote URLs - For example, based on that in Autrijus Tang's TPF Grant 2003 Report [perlfoundation.org]:

  BEGIN
  {
      use PAR;
      use lib 'http://localhost/DBI-1.37-i386-freebsd-5.8.0.par';
  }
  
  use DBI;
  
  print DBI->VERSION;

  (Naturally, the filename of the PAR archive could be changed to