Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of dietbuddha@gmail.com designates
 209.85.221.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=SSXz6wGr4lg3ztBPWSjhZaXgn5BzCdzEyL/qxVEDLO/ZChUUB4EmLbsC/Dhjx/Ll9Z
         YqJjyo/4w2Ny/IEi+1euiGgfvbTJeAvhOuUbdFvDGxI3yfbePowsK74Bx1F8xYSzQRQN
         BsTAzpv5pPO+MthWrE/wrtKrzHFxPQM1wCSLM=
MIME-Version: 1.0
In-Reply-To: <b6c5c4be0909250732k7794d563p3b8781e4adfb2218@mail.gmail.com>
References: <b6c5c4be0909100655n722b8914pfa945dc3dd0d63ca@mail.gmail.com>
	 <66887a3d0909100837p7ae69954rf13ce902b7a6e879@mail.gmail.com>
	 <b6c5c4be0909101008g75390bd9ve10c11e0faece77@mail.gmail.com>
	 <59a07310909110949l3b0a96e5j511cb63f8c8a488d@mail.gmail.com>
	 <b6c5c4be0909250732k7794d563p3b8781e4adfb2218@mail.gmail.com>
Date: Sat, 26 Sep 2009 00:41:42 -0700
Message-ID: <59a07310909260041t1f02d7do3aced0ff2de69468@mail.gmail.com>
Subject: Re: distributing software built on mod_perl
From: William T <dietbuddha@gmail.com>
To: Mike Barborak <barborak@basikgroup.com>
Cc: modperl@perl.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 25, 2009 at 7:32 AM, Mike Barborak <barborak@basikgroup.com> wrote:
> 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.

It's not limited to mod_perl.  It's limited to any shrink wrapped
software.  It's less of an issue with software that can be self
contained versus software that is shared on the system.

> 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

I would split up the distributable by "platform" since that is the
granularity you care about.

I usually rely on package that are already provided by various
distributions.  My target platforms are usually RedHat, Debian, and
FreeBSD which all have stable mod_perl+apache packages already, as
well as a significant number of perl packages available.  I then
backfill any packages which are not available for that distro so
really all I have to maintain is the difference between the packages I
use, and what the distributions already provide.

> 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

10 platforms seems a bit excessive, but then again it depends what
your counting as a platform.  ie.  RedHat/Debian, RHEL 4.2/4.3, or
RHEL 4/5.  If your platform is a distribution then your dependency
chain is different for each "platform" .  If your platform is minor
revision of a particular distribution, then it may not matter so much,
it's probably the same dependency chain.  If they are different major
versions, you can go either way depending on if it's common for both
major versions don't have too many differences in the dependency
chain.

In all cases though you want to leverage work already done by the
various distributions as well as third party package repositories to
reduce your own overhead.

> 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.

It's a tradeoff of up front work to figure out which platforms your
going to support, and what that means in terms of your dependency
chain, versus an unknown dependency chain and trying to mitigate all
the variance you may encounter in your support calls.

That isn't to say you can't take a middle ground as well so long as
the risks are understood.  It may in fact be cost prohibitive to do
the "right" thing" and track entire dep chains especially if your
trying to support a large number of platforms.  So the question
becomes what is "good enough".  How much can you maximize number of
supported platforms while minimizing support risk?

> 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.

There is is the idea of following your dependency chain until it is
"good enough" versus following it all the way to libc versions and
kernel versions.  My rule of thumb is to only follow language/library
which is what I would consider prime dependencies.  So I track what
versions of perl libraries I may use, or at least snapshot the package
repository, and checkin my custom packages.  Then periodically I sync
up with the distribution packages to update package versions.  For
each platform you want to support you create the package repository
snapshot.

-wjt