Re: Why MP2

[prev] [thread] [next] [Date index for 2004/12/16]

On Wed, 15 Dec 2004, colin_e wrote:

> Randy Kobes wrote:
>
> >Due to the large volume of modules on CPAN, ActiveState uses
> >an automated build system for their ppm packages...
> >
> I guessed I was looking at the result of automated build
> tests. However I naiively thought that Apache and mod_perl
> were so important to so many users they might get a little
> extra attention.

We like to think so :) However, there's quite a few popular
packages that also require human intervention in the build
process: GD, libxml2, various database drivers, ... And
these can be quite time-consuming in maintaining - building
and updating external libraries, sometimes tweaking things
that aren't always Win32-aware, interpreting failed tests as
either trivial failures or something indicative of a
fundamental problem, and so on. So, from a corporate time
management and quality point of view, it's understandable
why ActiveState has the policy they follow in providing ppm
packages.

Historically speaking, ActiveState (and the perl5
developers) have done an incredible job in providing a Perl
on Windows that works as well as it does (given, at times,
some fundamental limitations of Windows, compared to Unix).
Developers at ActiveState are quite active in maintaining
this, both in the core Perl development and, when asked,
helping us occasionally with pretty tricky problems with
Win32 mod_perl. Given that, I (and some others) are quite
willing to provide ppm packages for those modules which
escape ActiveState's automated build process.

> >However, if you install mod_perl via ppm (from our theoryx5
> >repository, or elsewhere), ppm will register and see it
> >for subsequent packages that require it...
> >
> I followed the install procedure documented at perl.apache.org
> (http://perl.apache.org/docs/2.0/os/win32/install.html#PPM_Packages).
>
> After having been bitten by the fact that the mod_perl
> installer blows up on pathnames containing spaces, forcing
> a teardown and reinstall (great...),

Pathnames with spaces can be a problem - we've tried to
catch these cases in the mod_perl build, but if we've
missed something, please let us know. In general, though,
installing both Perl and Apache in directories that
don't have spaces may avoid some frustration later.

> I installed Perl 5.8.4 and Apache 2.0.52 using their
> respective .msi installers. I then configured uwinnipeg as
> a PPM repository, and installed mod_perl from there.
> mod_perl shows up correctly in PPM as-
>
> ppm> prop mod_perl
> ====================
>     Name: mod_perl
>  Version: 1.99_17
>   Author: Doug MacEachern <dougm@xxxxx.xxx>
>    Title: mod_perl
> Abstract: Embed a Perl interpreter in the Apache/2.0.50 HTTP server
> InstDate:  14:33:24 2004
> Location: http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58
> Available Platforms:
>        1. MSWin32-x86-multi-thread-5.8
> ====================
>
> It's odd that Windoze needs a .dll manually installed,
> when on Unixes mod_perl.so is sufficient on its own.

The mod_perl.so (which is actually a dll) that a ppm
installation fetches and installs is done as a separate
post-install script because it needs to be installed outside
of the Perl tree (ie, in the Apache2 modules/ directory).
There's a few other packages that also do this - libapreq2
(for Apache::Request and Apache::Cookie) and XML::LibXML (a
Perl interface to libxml2), to name two.

> However as I read your mail, this means subsequent
> packages dependent on mod_perl should install ok IF they
> can be made available as PPMs. (It's a shame ActiveState
> doesn't get this far to enable all those defunct Apache::*
> PPMs to be built).

That's right - once mod_perl is installed via ppm, ppm will
recognize that mod_perl is installed when installing other
packages that require mod_perl.

> >As to the problem of there not being that many Apache-*
> >ppm packages available, there's at least three options:
> >
> >- send me a request for a particular package. I have a
> >semi-automated setup for making ppm packages, so it's
> >usually no problem to make one up. I'll look at in
> >particular doing one for Apache::CGI::Builder tonight.
> >
> This is terriffic, and much appreciated. As a newbie the
> process of getting Apache and mod_perl plus the addons
> packages running has been pretty painful (actually it was
> the Solaris compile+install that really drove me nuts). At
> the moment I have the Apache::CGI::Builder.pm manually
> pulled out of the .tar.gz download and copied into my Perl
> library, but it's not working correctly and I can hardly
> rule out a misinstallation.
>
> The particular packages that would be top of my list would be-
>
> * Apache::CGI::Builder

I've placed a ppm package of this (and its prerequisites) in
our http://theoryx5.uwinnipeg.ca/ppms/ repository. Let me
know if you have problems installing it. Perhaps such an
installation (as well as the prerequisites) will fix the
problem you had. The ppm installation should also install
html versions of the documentation in the location that
ActivePerl expects (and so should be available through the
ActivePerl documentation link on your Start menu).

> * Apache::SessionManager, dependent on-

Also in our http://theoryx5.uwinnipeg.ca/ppms/ repository.

> * Apache::Cookie

This is contained in the libapreq2 package in our repository
(which also includes Apache::Request). This is one of those
packages that requires an external dll (actually, two) to be
fetched and installed - installing libapreq2 via ppm should
offer to do this for you through a post-install script.

> I know I will need some of the ApacheAuth and Apache*LDAP
> packages at some point as well, but there are a ton of
> them and i'm not sure which combination I need yet.
>
> Thanks for the help. It encourages me to keep trying ;-)

You're welcome - good luck.

        -- 
        best regards,
randy

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html