Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Use whatever network files services your OS enables (like NFS,SMB).
    Then one server can be the master and the others can mount them.
  • 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-

  • 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
    • 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.

  • 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 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