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.

How we deploy massive Perl applications at work 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Thanks (Score:1)

    by berekuk (9275) on 2010.07.19 22:30 (#72186)

    Thanks for this, I would love to hear more similar stories from other people.

    In our case, we are still trying to be perfectionists and maintain >300 in-house .deb packages and several hundreds of hand-builded cpan packages as well.
    Actually, in our case our "application" consists of many various scripts and daemons, working on different hosts and clusters, so it is impossible to pack everything in one package anyway.

    I've been dreaming for a long time about fully-automated cpan-to-deb (and cpan-to-rpm) buildfarm which would build all cpan modules for every popular distribution. Actually, several of us from moscow-pm group tried to hack one recently, but nobody had enough cpan/debian toolchain experience to make it work yet. I wonder if we should ask for community help with it...

    • <p>I have just given up handling dependencies with one debian package per cpan distribution. For some time I have thought about how to build a bundle in the most maintainable way.

      <p>My current solution is to build a quite clean chroot of Debian Lenny and then use cpanm to install some modules in /usr/local and as the last step I'm making a package with everything in /usr/local. The chroot is build with:

      # debootstrap --arch amd64 --variant=buildd --include=cdbs,libwww-perl lenny /mnt http://ftp.s

    • We have something similar of course, web cluster + application server + integration server + internal web server, but we've found that it's easier to just deploy the whole project to all the servers, and only start up the parts that are relevant.

      For example, the internal and external websites share the same web application code, but the controllers and dispatch paths are only loaded into memory if that "profile" is enabled in configuration for that server.

      So while the public facing web servers do theoretica

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.