On Tue, 16 Jan 2001, David McCabe wrote:
> > From: Steve Reppucci <[EMAIL PROTECTED]>
> >
> > 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.)
>
> That is what I do as well. Plus, I use the prefix arg to
> build Apache as well, so a new mod_perl/Apache gets
> installed in a different dir than the current one when I
> run make install. I then copy over my config files to
> the new dir, and set up the new Apache to listen on a
> different port, then test it. Once tested, I point the
> sym-links for both Apache and perl to the new locations.
we go one step further and install perl and other libraries
with each version of our application, into say
/usr/local/webmail/5.0.0.1 or whatever. that way everything
the application depends on is in the version-specific
directory.
we drive our entire build and install process with make; the
whole process is something like this (abbreviated):
cvs co Makefile.webmail
make -f Makefile.webmail checkout build install rpm
checkout pulls all the library and application sources from
cvs and scps pre-compiled distributions from a package
machine. build compiles everything. install puts it into
/usr/local/webmail/<version>. rpm packages up the
installation directory. then to deploy in production, we rpm
-i on each machine, and a post-install script flips the
symlink to point at the new version. rollback is trivial.
