Painless Windows Module Installation with PPM
by Josh Stroschein
|
Pages: 1, 2, 3
Using PPM
Before I begin discussing my solution, it's worth covering some basics of the PPM program. To run the PPM program type at a command line:
C:\> ppm
PPM - Programmer's Package Manager version 3.2.
Copyright (c) 2001 ActiveState Corp. All Rights Reserved.
ppm>This, of course, assumes that you have the ActivePerl distribution installed on your system and the PPM program registered in your system path. If typing PPM at the command line yields no results, find it in the bin\ directory of your ActivePerl installation. ActivePerl installs to C:\Perl\bin\ by default. Change to that directory and then type:
C:\Perl\bin> ppmYou know you are in the PPM program when the command prompt turns into a ppm> prompt. Once inside the program you can display all of the repositories available on that system by typing:
ppm> rep
Repositories:
[1] ActiveState Package Repository
[2] ActiveState PPM2 RepositoryWith a default installation you will see a couple of repositories that begin with ActiveState. These are the ones I mentioned earlier. They are the default repositories that ActiveState maintains. If you are connected to the Internet you can execute a search by typing:
search <Module Name>If your search produces results, the result will be a list referencing each match by a number, the package name, and a brief description. Here is a search for everything in one of my local repositories:
ppm> search *
Searching in Active Repositories
1. Crypt::Blowfish [2.10] Crypt::Blowfish
2. Date-Formatter [0.04] A simple Date and Time formatting object
3. DBD-Mysql [2.04.1] MySQL drivers for the Perl5 Database Interface ~
4. DBI [1.14] Database independent interface for Perl
5. libwww-perl [5.48] Library for WWW access in Perl
6. Win32-Daemon [0.2003.~ The Win32::Daemon extension for Win32 X86. Allo~Installing a module is just as easy. However, before you can install a module, the PPM program needs to create a reference to it. Accomplish this by searching for the module. Upon completion of the search you can refer to the module by the number that corresponds to it. To install the module at position one, in this case Crypt::Blowfish, in the previous results list type:
ppm> install 1The PPM program will let you know if the module installed successfully or failed. PPM offers other commands to make managing your modules easier. However, this is all I needed for my solution... except for creating a local repository.
Creating a Local Repository
There are a few basic elements to a local repository: the directory structure, the PPD files, and the modules. Initially, the PPM program gave me some difficulties locating the modules I needed to install. By trial and error, I discovered that the problem was the directory structure in which I had set up my repository. A repository needs two directories, one to house the PPD files and the other to contain the actual modules in their .tar.gz format. Because the most common architecture for these installations is the x86 architecture, I created a directory named packages with a subdirectory named x86. The important thing about the directory structure is that the actual modules go into a subdirectory. This is opposed to housing the PPD files in one location and then storing the actual modules in an entirely different location in the file system.
As I have mentioned earlier, this installation package was designed for Windows 2000 and later. I encountered numerous problems with the PPD files not being able to reference module locations based on an absolute path. I also encountered random errors when I used a relative path to a location other than a direct subdirectory. So where does the PPM program find this information?
A PPD file is nothing more than an XML document. This XML document contains all the information needed by the PPM program to install a module. Here is an example PPD file for the libwww module:
<SOFTPKG NAME="libwww-perl" VERSION="5,48,0,0">
<TITLE>libwww-perl</TITLE>
<ABSTRACT>Library for WWW access in Perl</ABSTRACT>
<AUTHOR>Gisle Aas</AUTHOR>
<IMPLEMENTATION>
<DEPENDENCY NAME="Digest-MD5" VERSION="0,0,0,0" />
<DEPENDENCY NAME="HTML-Parser" VERSION="0,0,0,0" />
<DEPENDENCY NAME="MIME-Base64" VERSION="2,1,0,0" />
<DEPENDENCY NAME="libnet" VERSION="0,0,0,0" />
<DEPENDENCY NAME="URI" VERSION="1,03,0,0" />
<OS NAME="MSWin32" />
<ARCHITECTURE NAME="MSWin32-x86-object" />
<CODEBASE HREF="x86/libwww-perl.tar.gz" />
</IMPLEMENTATION>
</SOFTPKG>Notice the name attribute in the <softpkg> element. The PPM program queries this attribute's value when you perform a search. The <implementation> element also includes some very important attributes. Inside this element you can declare dependencies inside <dependency> elements. This example PPD file includes several dependencies that must be met in order for this package to install successfully. The PPM program will check the system for the installation of these modules and, much like installing a Linux RPM, will fail if it can not find them on the system.
One of the most important elements in the PPD file is the <codebase> element. The HREF attribute directs the PPM program to the location of the module. Remember the packages directory? Fill the x86 directory with the .tar.gz download of the modules you want in your repository. Then supply the relative path to them in the HREF attribute so that the PPM program will be able to locate them. You may also use URL to refer to a location on the web or on a local network. It's entirely possible to create a local repository that only references modules located on other servers, instead of supplying all the modules locally. By supplying a URL, your repository could point the PPM program to another location on a network or over the Web.
I experimented with this tag quite extensively. The biggest problem that I encountered was trying to reference a module in the HREF tag by its absolute path. On certain versions of Windows, the PPM program would always fail, citing a variety of errors. Once I created the appropriate directory structure and supplied the PPM program with a relative path, it found the modules successfully. Visit ActiveState's website for a complete breakdown of the PPD file structure and all of the supported elements.
You should now be able to create your own PPD files. Just keep in mind that if you can not build the module on your system by the standard:
perl Makefile.PL
nmake
nmake test
nmake install... approach, then PPM will probably not be able to install them successfully either. PPMs exist to ease the installation of modules successfully built and tested in a Windows environment.
For each module that you want in your repository, create a PPD. The example provides a good starting template for a PPD file. From a blank text document, insert the corresponding data in XML format. Once you've inserted the relevant information, save the file with a logical name and the .ppd extension. I typically use a name that closely mimics the one used in the <title> element. The PPD files must go in your repository's packages directory. Once you have created all of the PPD files and downloaded the modules into the x86 directory, you're ready to set up the repository in PPM.
