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. Mike On Fri, Sep 11, 2009 at 12:49 PM, William T <dietbud...@gmail.com> 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. > > YMMV > > -wjt >
