On Mon, 9 Jul 2001, Forrest Cahoon wrote:
> Our sysadmin here brought our development machine up to OpenVMS 7.3, and
> with it installed CSWS (Compaq's supported version of Apache). (Yay!)
Congratulations.
> When he did this, he installed Compaq's perl kit, so that machine now has a
> new PERL_ROOT. Our production Perl tree, which was built from sources, has
> about a gazillion modules installed, that I'd like to move over to this new
> perl tree in as painless a way as possible.
>
> Can I just do a copy something like this
>
> $ copy OLD_PERL_ROOT:[LIB.SITE_PERL...]*.*;
> NEW_PERL_ROOT:[LIB.SITE_PERL...]
>
> or are there other files that need to be copied?
I would not do that if I were you.
> Is the risk of hosing things substantial enough that I should just install
> all the modules from sources again into the new tree?
I would say that the risk of screwing things up is so great that there are
almost no reasons not to build things from scratch. You mentioned a
"gazillion modules", the easiest way to obtain a summary of what got
installed after running `mms install` for perl is via the online
documentation system:
perldoc perllocal
will list all distributions that were installed via
`perl Makefile.PL\nmms\nmms test\nmms install`. It is a handy list and
can be edited directly in the file perl_root:[000000...]perllocal.pod.
In going through such a list you may want to compare the versions of
things installed versus what is currently available on CPAN. _Most_ of
the time newer versions of things have more bug fixes and/or features. On
rare occasions sticking with an older version of a module distribution is
necessary for any of several reasons: 0) buildablity on VMS, 1)
buildability under 5.005_03, etc.
Yet another summary of installed files is available via the
ExtUtils::Installed module like so (there is an emphasis on uncovering
missing files in the following code - be sure to read the pod
documentation for ExtUtils::Installed in order to re-write this to obtain
a list of installed files):
use ExtUtils::Installed;
my $installed = ExtUtils::Installed -> new();
my @modules = $installed -> modules();
my @missing = ();
my $version = undef;
for (@modules) {
$version = undef;
$version = $installed -> version($_);
if ($version) {
print "$_; $version\n";
}
else {
print "$_; NO VERSION\n";
}
@missing = ();
@missing = $installed -> validate($_);
if ($#missing >= 0) {
print join(' ',@missing),"\n";
}
elsif ($#missing == -1) {
print "$_ all files present and accounted for in .packlists\n";
}
}
> The versions are the same, 5.005_03, so moving files seems plausible. But
> I'd really hate to mess things up.
About the only time that I would consider not building things from scratch
is when installing on a large number of nearly identical machines: OS
VERSION, C compiler, MMS utility, TCP/IP stack, domain name, etc. In such
a case I would build everything from scratch into a freash new PERL_ROOT,
install all modules, then BACKUP the new PERL_ROOT into a saveset that I
would then feel somewhat comfortable with BACKUPing onto each separate
machine. Even in such a case it would be useful to go in an tweak things
like the config.pm and config.sh files for certain node specific variables
such as the following:
$ perl -"V:cf_by"
cf_by='pvhp';
$ perl -"V:cf_email"
cf_email='[EMAIL PROTECTED]';
$ perl -"V:myuname"
myuname='VMS corrie V7.1 AlphaServer 2100A 5/250';
I would consider the BACKUP saveset in cases where I needed to install the
build on more than 10 machines running VMS V7.1 on AlphaServer 2100A
5/250. Otherwise I would build everything from scratch.
Doing things "from scratch" can be automated to whatever extent you want.
On Unix and NT+Cygwin I have a Bourne shell script that will build perl
then install extensions from a central NFS mount point (you can earn big
bonus points if you can figure out why it is Bourne shell and not written
in say perl :-). On VMS suppose that I had a list of VMS friendly module
names:
XML-WRITER-0_4.TGZ
XML-SIMPLE-1_04.TGZ
STRING-CRC32-1_2.TGZ
I could then write (this is untested code and may need tweaking):
$!
$! Multiple perl module builder in DCL - pvhp.
$! Presupposes that 'perl', 'gunzip', and 'tar' are available (foreign
$! symbols usually)
$!
$! Are we using MMS or MMK? Store in make_util symbol:
$ perl "-MVMS::DCLsym" "-MConfig" -e "tie
%s,VMS::DCLsym;$s{'make_util'}=$Config{'make'}"
$! adjust this symbol to suit your module list file location:
$ LIST_FILE := DISK:[DIR]MODULES.LIST
$ open/read/error=list_err LIST 'LIST_FILE'
$another_module:
$ read/end=list_end/err=list_err LIST line
$ name = f$parse(line,,,"NAME",)
$ copy/log 'line' []
$ gunzip 'line'
$ tar -xvf 'name'.tar
$ set default [.'name']
$ perl Makefile.PL
$ 'make_util'
$ 'make_util' test
$ 'make_util install
$ write sys$output "installed ''name'"
$ set default [-]
$ perl -"MFile::Path" -e "@d=map(VMS::Filespec::unixify($_),@ARGV);rmtree(\@d,0,0)"
[.'name']
$ goto another_module
$list_end:
$ close LIST
$ write sys$output "All done"
$ exit
$list_err:
$ close LIST
$ write sys$error "Error encountered while processing ''LIST_FILE'"
$ exit
I hope that helps.
Peter Prymmer
