Thanks for all the references. I looked through them.

I think the issue is confusion over the role of a "build system" and a "package and deployment system". A very good system, in my opinion, is the rpm/yum/repos system that RedHat uses (others may bring up apt-get and Debian which is also good). These packaging systems have the ability to do automatic dependency checking (just like CPAN). They also have the ability to do rollback, as well as package things other than Perl (unlike CPAN).

We already have enough good _build_ systems. They are as old as the hills, and things like make are still around, proving their value. Perl has it's own build systems which solve many of the same problems. Fair enough. But we don't need more solutions in this area. So Shipwright doesn't seem useful to me on first glance. No need to have another build system that is less known, has no docs, etc. Problem already solved.

There does seem to be a realization somewhere by some that it would be "a good thing" if CPAN could automatically make RPMs. Of course, the devil is in the detail on these things, and while you can automate 99% of this, there is a 1% that requires everyone who has ever written a module to do a little work. Having automatic RPMs from CPAN would be, in a word, awesome, because you can get the benefit of the rpm/yum/repos system which is goes far beyond CPAN (in terms of deployment functionality). Further, this system will only get better.

Note there is a tool, cpan2dist that does this. Give it a try and you'll see why there's a long way to go before we have full CPAN to RPM automation.

So I'll employ a hybrid deployment strategy. I'll maintain a separate perl stack, independent of the vendor perl, which is updated via a MicroCPAN installation of just my modules, mounted by fuse (so it looks like a file:///url). Everything else will be RPMs. Making perl RPMs has proven to be too much trouble (because of the many dependencies on CPAN-RPM modules).

Note, none of the tools mentioned above even comes close to providing the needed functionality (but thanks for the list). I would go a bit further and build something on top of rpm/yum/repos for repeatable deployment to a cluster of machines. But note, you need all the underlying machinery to work well for this to happen (e.g. rollback)

What is the functionality you're after that none of this provides?

I worked on the Krang system and, although I now think building from source every time was a bit slow, that system does allow you to install a specific set of modules with an application without disturbing anything else on the machine. It means you can install a dozen different versions of the app, with different versions of the same modules, on one machine. RPM could maybe do that if you use relocatable RPMs, but I'm not sure it would work with XS modules.

Shipwright does that as well, and also seems to handle dependencies between modules. The dependencies are the main thing that makes the CPAN shell so attractive: tell it to install Moose and come back in 30 minutes and it will have grabbed everything needed. When using things like RPM, you have to build that yourself. I've tried it with cpan2rpm and a wrapper script that tries to look up dependencies and download them. It's hard to get it 100%. Maybe CPANPLUS/cpan2dist get closer.

I'm more interested in the foundations of a deployment system based on packages.

Some motivation would probably be helpful. Imagine hundreds of servers, in several classes, provisioned, say from Amazon Web Services. Perl is a perfectly good language to for many distributed applications. We want the ability to deploy a distributed "application" to these tiers. Using packages this is a possibility, provided we have enough of the basic mechanisms (Rollback is a major one, installing without interactivity another).

First off building from source is not the way to go. There have been a variety of systems like this, and they wind up being more trouble than they are worth. The canonical example being Gentoo linux, or Mac ports, which pull all the source and build everything. While this approach is useful, it just takes too much time. Rebuilding things from source every single time is a great way to sop up that extra processing time, but not a great use of human time. Building from source is a way to insure that we can move to new architectures, but it should not be the default way to upgrade a system. RPMs work just fine, are fast and convenient.

When one deploys software, there is always the chance of failure, so one wants to be able to roll back to the previous version. RPMs provide this ability, but CPAN does not.

I'm a little prejudiced in that anything that seems like a global build system is not the way to go. I'm not saying this can't be made to work, but these systems tend to rely on things like rebuilding everything from scratch, rather than on package dependency algorithms which determine what to upgrade (suffering from this on Mac ports at the moment). If you can't rebuild everything, you must instead try to find packages which satisfy some dependency constraints. This winds up working better when done properly.

Another issue is that CPAN is designed to be like a giant Borg rather than individual repos which hold portions of the packages. The problem with this is it requires one to do silly things like keep a MiniCPAN to do distributions. While it is possible to get things working, the devil is in the details...all the tools want there to be a CPAN + your local modules to work. Things don't work well when you violate this, but you can see all of the tutorials and tools start from some mirror and add a delta to that. Not a scalable approach in general.

Rollback is different than regenerate.