Not that I have an answer to this complete problem, but I have had similar
situation, so I'll also be interested in the solutions you uncover.
I've always handled the support of multiple perl versions by installing
new versions of perl using a prefix like /usr/local/perl/5.6.0, etc.,
(I also place CPAN's build directory under that tree.)
This makes it easy to install and test new versions of perl without
affecting running applications that have been built against a previous
perl version, as well as making it possible to test with specific versions
just by referencing the appropriate version in the script's shebang line
(or by setting my PATH appropriately when building mod_perl.)
Using this method, I symlink the "current default" version of perl and its
tools in the standard public directory (/usr/bin or /usr/local/bin).
Upgrading mod_perl versions has been a headache though, as I'm similarly
hesitant to simply 'make install' new mod_perl releases without being able
to test that all of my running applications work correctly. I suppose
your idea of archiving the lib tree (/usr/local/perl/5.6.0/lib in my
setup) before running the 'make install' so that it's easy to roll back
should something fail is prudent. But it still doesn't solve the problem
of being able to fully install (in its real final location, not in a
private directory...) new versions of mod_perl without affecting stuff
that's already running. (Maybe I'm just tilting at windmills in worrying
about testing modperl from a private directory install...)
So how *do* others handle this upgrade situation?
<Steve>
On Tue, 16 Jan 2001, Bill Moseley wrote:
> This is a revisit of a question last September where I asked about
> upgrading mod_perl and Perl on a busy machine.
>
> IIRC, Greg, Stas, and Perrin offered suggestions such as installing from
> RPMs or tarballs, and using symlinks. The RPM/tarball option worries me a
> bit, since if I do forget a file, then I'll be down for a while, plus I
> don't have another machine of the same type where I can create the tarball.
> Sym-linking works great for moving my test application into live action,
> but it seems trickier to do this with the entire Perl tree.
>
> Here's the problem: this client only has this one machine, yet I need to
> setup a test copy of the application on the same machine running on a
> different port for the client and myself to test. And I'd like to know
> that when the test code gets moved live, that all the exact same code is
> running (modules and all).
>
> What to do in this situation?
>
> a) not worry about it, and just make install mod_perl and restart the server
> and hope all goes well?
>
> b) cp -rp /usr/local/lib/perl5 and use symlinks to move between the two?
> When ready to move, kill httpd, change the perl symlinks for the binary,
> perl lib, and httpd, and restart?
>
> c) setup a new set of perl, httpd, and my application and when ready to go
> live just change the port number?
>
> Or simply put - how would you do this:
>
> With one machine I want to upgrade perl to 5.6.0, upgrade your application
> code, new version of mod_perl, and allow for testing of the new setup for a
> few weeks, yet only require a few seconds of downtime to switch live (and
> back again if needed)?
>
> Then I wonder which CPAN module I'll forget to install...
>
>
>
> Bill Moseley
> mailto:[EMAIL PROTECTED]
>
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
