make 2 directories:
/opt/local1
and
/opt/local/2
do an original install in /opt/local1, perl http mod_perl what ever packages
you need etc. when it is time to upgrade do a new install in /opt/local2 of
what you need, run the httpd on an off port, i.e. port 8765, until you get
the new stuff working correctly. turn off the old httpd and move the new
httpd to port 80, now you have achieved upgrade with a clean name space.
when you are sure that everything is working backup /opt/local1 and delete
all the files in it. the next upgrade you need to do use /opt/local1 as the
build area.
marc
----- Original Message -----
From: "rolf van widenfelt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Bill Moseley" <[EMAIL PROTECTED]>
Sent: Friday, January 19, 2001 3:09 PM
Subject: Re: Upgrading mod_perl on production machine (again)
>
> face it, you are trying to perform surgery on a live subject...
>
> with all the Makefiles you'll be making, (httpd, modperl, perl...) you're
bound
> to slip
> on one of them and install over some of your existing stuff.
>
> i went thru a conflict like this once, and avoided it by simply getting
> a second machine, and installing all the new stuff there.
>
> but, if someone can offer a procedure for setting up two independent
httpd+modperl+perl
> environments on one machine it would be pretty interesting!
> (sorry, if this was already outlined in the responses last Sept)
>
> -rolf
>
> Bill Moseley <[EMAIL PROTECTED]> writes:
> >
> > 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).
>
