We use Perl on many machines here, and have been suffering from different versions of modules being installed on development and production boxes. We're looking to do something about it, and I wanted to get some insight from others who may have tackled this.

We use Subversion fairly extensively, and we roll code changes into production via an export, so we figured it was a natural extension to store module source in a repository too. Then, when installing/updating a machine, we go simply export an additional repository (third-party modules) in addition to the existing ones (internal modules, application code).

We've also patched some third-party modules to add or change functionality to suit our purposes. Where possible, we've contributed these changes back, but in some cases this hasn't been possible. Because of this, our desire is to keep unpacked distribution source in Subversion rather than a tarball.

The packages are actually installed into a seperate directory rather than into the various system Perl locations (with all our code using an appropriate "use lib" line). We do this because we're an applications group and don't get root access to our machines.

We figure that we'll have the following tasks to do:

• Install a new module
• Upgrade an existing module (which may mean a later version of a core module).
• Reinstall an existing module (eg after we patch it)
• Compile and install everything (bootstrapping a new machine)

When installing/upgrading, I'd really like dependencies to be figured out so stuff is installed in the proper order. This information would be cached so that when a new machine is installed the modules are built in the correct order.

I've looked into the stuff that CPAN::Shell provides, and it looks like it knows how to do everything I need (download, calculate dependencies, build, test, install), but it doesn't really seem to be suited to this task. As far as I can tell, it can't be made to use an existing unpacked source directory, preferring to extract its own from a cached tarball. It also can't seem to calculate dependencies without trying to do the entire build, which I don't want to do if I can help it.

autobundle isn't helpful in this case, because I expressly don't want a list of core modules. I'm also not sure if it would install the exact version numbers I want. And besides, there's no scope for installing our own patches with it.

I suppose Module::Depends will figure into the equation somewhere (though I find its rather extensive list of dependencies somewhat amusing; I would have expected them to be kept to a minimum).

Another though I had is to carve up dh-make-perl. We're not using Debian here, but it seems to be able to manage to do alot of what we want.

So what have others done in this scenario? I can't believe we're the first to come up against it. Any guidance you can offer would be greately appreciated.