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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Thanks (Score:1)
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) bui
Re: (Score:1)
<p>My current solution is to build a quite clean chroot of Debian Lenny and then use cpanm to install some modules in
# debootstrap --arch amd64 --variant=buildd --include=cdbs,libwww-perl lenny
Re: (Score:2)
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
cpan mirror (Score:1)
How do you maintain your CPAN mirror? What is your process for verifying that updated modules are needed or allowed? How do you mark packages you do not want to update?