At 12:01 PM 4/3/2001 -0400, John Peacock wrote:
>Peter Prymmer wrote:
>(the scenario I have in mind is picking
>> up an older version of a module that gets installed on the later version
>> of perl on VMS in a place where the @INC array sees the prior version
>> before the later version).
>
>This is always a risk in Unix environs as well; I would prefer to not
>nuke my perl_root if I am building binary compatible modules. I also
>hate to reinstall all of my modules when I reinstall Perl. The Unix
>install does warn about where site_perl is now located.
>
>My vote would be to take the existing PERL_ROOT logical as the default
>installation target then issue warnings about what needs to be checked,
>as you offered above. A note in README.VMS about dropping the
>PERL_ROOT logical before running CONFIGURE.COM would be great for the
>users who need something different. DWIM should be followed for the
>core as much as it is for the modules, IMHO.
Hmm. Personally I can't imagine a situation where I would install Perl on
top of an existing installation, at least on a production system. It's so
easy to create a parallel installation, test it, then flip the switch to
point to the new one. That way you increase the reliability of the
transition to a new version with zero down time. Rebuilding all the modules
is a pain but can be scripted. I might cheat a bit and use the BACKUP
command to move some of the contents of perl_root:[lib.site_perl] from the
old installation to the new, but only if I knew the modules were either pure
Perl or binary compatible.
>Since Perl doesn't take well (in general) to being moved about after
>being built,
Sure it does, at least on VMS. Just take a snapshot of a working Perl tree,
put it wherever you want (minding directory depth where necessary) and point
perl_root at it. This used to be the only way to do things before the
install target worked.
>it really makes little sense to install in the current
>build directory in any case.
I do agree with that, especially since you burn up twice as much disk space
as necessary if you use the build tree as an installed location. I think
it's done this way merely because it's a safe place to test the install
target and you do wind up with a working Perl that you don't have to move if
you don't want to.
>Anyone who is planning on having two
>installations of Perl in parallel has to know what they are doing in
>any case, so that would not be much of a suprise to them.
But the current way, someone with only one installation cannot possibly
overwrite it unless they explicitly choose to.
