perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Barborak <>
Subject Re: distributing software built on mod_perl
Date Fri, 25 Sep 2009 14:32:45 GMT
I think I see what you're saying. It seems like a very expensive
problem to solve. It must be a barrier to people choosing mod_perl to
develop their apps because it might be the case that their
distribution and installation process is more complex to develop and
support than their actual applications. That's what it's looking like
in my situation and so I'm going to reevaluate using mod_perl.

But it seems like there's a lot of generally repurposable results in
your efforts that could make distributing mod_perl applications more
straightforward. It seems like at the core of what you do is a massive
distributable that contains:

* mod_perl binaries
* perl binaries
* necessary perl module binaries
* project-specific binaries

This massive distributable contains these binaries built for all the
supported platforms and all the supported versions of Apache. So if we
say that there are on the order of 10 platforms that need to be
supported to cover 95% of all installations and there are 5 versions
of Apache to support (just guessing with both numbers), then it would
be a matter of building:

* 50 versions of the mod_perl binaries
* 10 versions of the perl binaries (multiplatform installations
supported by perl already)
* 10 versions of the necessary perl module binaries (multiplatform
installations supported by perl already)
* 10 versions of the project-specific binaries

This would take a lot of effort to setup but doesn't seem unreasonable
to maintain. And with this binary repository in hand then it seems the
distribution problem really does become fairly straightforward; it's
just a matter of figuring out the target platform and apache version
and then producing an appropriate apache configuration snippet. That
seems a lot easier than trying to walk a client through the process of
getting the development version of apache, getting the necessary build
tools, building mod_perl, building perl modules, etc. It also seems
like it would make less of an impact on a client's existent system
that replacing their web server.

So is it a pipe dream to think that such a repository of
non-project-specific binaries could be made publicly available to
mod_perl application developers? Some of the problems I see are:

* Have I captured all the variants or would you also have to build
version for all the various versions of libc, mysql, etc.?
* For customized perl modules and your own application, what would the
resource be to build it on all the supported platforms? Perhaps this
is where someone could monetize this scheme.

I'm not expecting such a thing would be available any time soon and so
wouldn't affect my decisions but I just wanted to put this out there
as food for thought. It seems like my situation isn't that odd and so
is an interesting case study arguing that mod_perl isn't being as
broadly used as it might be.


On Fri, Sep 11, 2009 at 12:49 PM, William T <> wrote:
> Whenever I creating shrink-wrapped software I always make packaging
> and distribution part of the development, qa and testing process.  All
> packages for the platforms that we will be supporting.  The reason I
> do this is to cut down on the customer support overhead.  I've found
> you get less calls and emails regarding installation.  And more
> importantly when it comes to supporting the customer they all have the
> same installation per platform which often times makes things much
> easier to debug (or at least removes alot of potential sources for
> problems).
> In practice what this means that we have an additional make target,
> package which creates the appropriate package for the platform it's
> running on.  I also have automated unit test which pull apart the
> installation verifying meta data and install bits, as well as running
> the installation in a sandbox to verify installation occurs without
> issue.  It can be alot of upfront time to set this up, but very little
> maintenance is required once it's up and running.
> -wjt

View raw message