On Tue, 3 Apr 2001, Craig A. Berry wrote:
> 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.
A place where you might do that is on Unix where you do not want to have
to change all of your scripts #! lines to accomodate a new perl location.
In such places you overwrite identically named files, but can retain
dissimilarly named files. A typical example is an ISP that needs to
support both perl4 and perl5. They might use /usr/local/ as the $prefix
for both but have one binary named, say perl5, and the other perl is
4.036.
> >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.
Yes this has worked for ages on VMS. I've used it on production perl
installation here where I've needed to shuffle things around devices as
we've installed/removed drives etc. Perl can also be moved on MacOS - at
least the MacPerl application can be moved. If you want to move the MPW
tool you will have to ensure that your new location corresponds to your
"{MACPERL}" MPW Shell environment variable, but that is analogous to
changing your perl_root DEFINition in perl_setup.com on VMS.
Windows NT perl's have a relocatability feature too: my understanding from
Gurusamy Sarathy is that the perl.exe startup on Windows looks at it's own
location (argv[0] perhaps?) then sets the relative @INC directories with
respect to that location. You can, and I have successfully done, move a
perl from say C:\perl\... to D:\myperl5\... without a hitch. The place
where you cannot relocate perl is on Unix - more or less for security and
performance reasons. The hardcoded path locations are typically under
the aegis of a permission savvy system administrator and perl on unix does
not need to call getenv() or stat the file system just to start up like on
the non-Unixes. If you want to experiment with a binary relocatable perl
on Unix you might be interested in nsperl which used to be available from
http://people.netscape.com/kristian/nsPerl/ but I see that that link is
now gone. Also on Unix with the Bourne Configure you can specify and
installprefix that allows making a tar archive quite easy (instead of
installing into /usr/local and having to be extremely careful about
tarring up non-perl stuff you can now build with
sh Configure -Dinstallprefix=/tmp/perl -Dprefix=/usr/local
then after `make install` run something along the lines of:
cd /tmp/perl
tar -cvf usr_local_perl.tar .
Unfortunately you also have to tweak the Config.pm and you cannot install
CPAN modules into an $installprefix installed perl tree on Unix (not yet
anyway ;-)
> >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.
`mms clean` is your friend. Perhaps we ought to document that more
prominently in README.vms? Perhaps too we ought to give an example of a
_proper_ prefix setting in README.vms?
> >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.
Another advantage of the current _default_ (but overridable) value of
prefix on VMS is that you can tell with:
show logical perl_root
which version of perl you are using (as if perl -v were any harder?).
How about if we set the default to a similar string to the build
directory:
e.g. build e.g. dflt prefix
DKA100:[PERL-5_6_1] DKA100:[PERL_ROOT-5_6_1.]
OK - so how about something like that?
Peter Prymmer
