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