ChrisS has asked for the wisdom of the Perl Monks concerning the following question:

I have been asked to assume maintenance responsibilities for a corporate ActivePerl installation on Win32, and could use some advice.

I know I need to upgrade due to a bug in the currently installed build, but we have already installed a variety of modules that need to stay. I did not perform the original install, and don't know which modules have been added before I took this task. Is searching for the .pm files under the @INC folders really enough? How would you find all the modules an installation of Perl knows about? (For example, we use the Mozilla LDAP SDK, which might be a problem.)

We also have a large body of in-house scripts, which have been placed in a folder under the root Perl folder (called scripts) that are expected to stay there (again, not my call.) So, once I know what modules we need, how can I manage the upgrade and minimize the disruption to the users?

Useful tips on maintaining a Perl installtion (or links that provide said info. are certainly welcome.)

Thanks!

Replies are listed 'Best First'.
Re: Maintaining a Perl Installation
by blueAdept (Beadle) on May 06, 2003 at 17:20 UTC
    Sounds like you have a lot of poor planning from the previous support person to amend. (doesn't seem wise to keep custom scripts under the perl directory)

    Figure out all the non-core modules you need by parsing all your scripts, who cares what .pm files are actually installed..you just care about the ones being used. Then download the .ppd and .tar.gz files for each module from the appropriate site(s).

    After that write a script to automate the installation of all those modules. You'll need to modify the path within the .ppd file to match that of the locally installed/copied .tar.gz files.

    ActivePerl is pretty simple to install silently, check the docs for exact syntax/options. In the environment I work we use SMS(ugh), so I have an SMS issuance that installs perl itself and then runs my script to install the extra modules. I do something like this to install Perl itself: 

    msiexec.exe /I blah.msi TARGETDIR=D:\PERL AddPerlToPath=NO /q

    [download]
    and my install script for the modules that runs after perl itself is installed is like this : 
    use PPM;
....
   # array of fully qualified path to each .ppd file
    for ( @modules_to_install )
        {
        print "Attempting to install $_\n";

        if( PPM::InstallPackage("package" => $_) )
          {
          print "Successfully installed $_\n";
          }
        else
          {
          print "Failed to install $_\n";
          $errors++;
          }
      }

    [download]

    Note: I wrote my automated module install script before ppm3 came about, so there may be newer ways/abilities to do this. After thousands of successful installs it has worked very well. If the server was healthy enough for Perl itself to install from the .msi file then the module install script always ran successfully for me.
[reply]
[d/l]
[select]
      ppm3 is the name of the new console.
      PPM.pm has not changed that much (a few bugfixes, some additions, but pretty much the same -- PPM::InstallPackage is there)

      I for one dislike how ActivePerl handles the PPM distribution (no test suite is not good), but it's their product, so I can't do much about it (the last cpan release is PPM-2.1.6).

      MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
      I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
      ** The Third rule of perl club is a statement of fact: pod is sexy.
[reply]
Re: Maintaining a Perl Installation
by tall_man (Parson) on May 06, 2003 at 16:55 UTC
    Each perl module that is installed is added to a "perllocal.pod" file in your perl library tree. Looking at this would be a good start.
[reply]
      But wouldn't that depend on how they "installed" the module? ("Bad developers, bad! Don't copy those files into the directory structure.")

      I did look at the file, and it contains more entries, so you certainly have helped me get further along.

[reply]
        Kinda (btw, searching for the .pm files under the @INC folders really is enough).

        I refuse to install any module without ExtUtils::MakeMaker, even if I have to write a Makefile.PL myself (i do it for modules I release here on perlmonks), and so should you.

        Why? Precisely because I like my perllocal.pod's updated when I add modules. I also like my .packlist's properly maintained, so I know exactly what came with each distribution I installed (by using ExtUtils::Installed). PPM does it, and so should every module installing mechanism ;)

        It is also one more reason I don't use Module::Build, because as of yet, it doesn't modify the two perllocal.pod (it's on the TODO list).

        You should also check out Module::Corelist, ActiveState may add a bit more modules to their core, but Module::Corelist is still useful nonetheless.

        Also, Module::ScanDeps may be of interest to you.

        update: I forgot to mention to beware of software which deletes/overwrites your perllocal.pod (like Everything).

        MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
        I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
        ** The Third rule of perl club is a statement of fact: pod is sexy.

[reply]
Re: Maintaining a Perl Installation
by draconis (Scribe) on May 06, 2003 at 17:18 UTC
    You have a very difficult job ahead of you. Checking perllocal.pod will only provide the locations of the modules installed. It will not provide the locations of modules dropped and explicitly referenced via a modification to @INC from within a script.

    A scan of the drives for *.pm may be beneficial to your findings and help you locate potential locations other than the standard install directories where "orphaned" modules may exist.

[reply]

Back to Seekers of Perl Wisdom