In my experience install and copy, especially for a large bundle, isn't reliable. You'd (a) have to do a diff on all directories where files might be found (b) insure that there was no other cause for the differences you find (c) insure that none of data generated by the installation process (e.g. configuration files) contains machine specific or network node specific information). In addition to /etc, some applications place material in various places in /var, /lib, /usr and its subdirectories, /usr/local and its subdirectories, etc, etc. The snapshot approach also presents several maintenance problems. Every time an application gets updated the snapshot has to be regenerated. It is hard to uninstall. Upgrades can be a nightmare because snapshot images are better at adding files than deleting them.

When all software comes from a single source (CPAN, Debian, Ubuntu, etc) then the packaging system can usually handle dependencies. Even CPAN has support for creating a software bundle that can be used to automatically download a bunch of dependencies for your main program.

When software comes from multiple sources things can get a lot more complicated. However, many of the *nix OS (Debian, Suse) provide a way you can download software and bundle it into system supported packages on your own. There are even CPAN modules that can do that (search CPAN for rpm), though I don't know how reliable they are. If at all possible, try to use those packaging systems.

There are also a number of services on the web that purport to multi-source software from many repository and vendor websites. However, I don't think these are likely to meet your needs. The ones I've seen are all for MsWin desktop apps and rely on not-so-reliable techniques like html scraping to guess at the download location.

You may also want to investigate some of the cluster management systems. There are several open source systems available for distributing software and updates over large numbers of look-alike machines. I don't know how compatible any of these are with Apple Xserve, but you can look into Puppet for starters if your are interested.

Another creative solution I've seen to this problem is to bundle the application stack into a "virtual appliance". Instead of installing the applications directly on the machine, one installs the appliance. This, of course, means that all service requests go through a double layer. That may cause an unacceptable performance hit. Then again it may not. Virtual machines these days are pretty fast. You will still need to rebundle and reinstall every time one of the components of the stack gets updated. However, since you are installing a complete self-contained system rather than overlaying a snapshot on an existing system, you will avoid most of the other issues with snapshot generation and updates mentioned above.

In the end you may need to consider writing your own installation script to download and install applications for each machine. I've been on projects where this turned out to be the only viable solution. But this too is fraught with dangers: testing such a script and insuring it is reliable may take as much time or more than hand installing. It also needs to be updated from time to time so that it fetches whatever happens to be the latest version of app X that you have approved. An update feature for security patches is not a bad idea either. As you can see, this quickly turns into an application in its own right.

It might be worth it all the same if you are upgrading repeatedly, scaling up over a large number of machines, or need to factor in time spent on system failures. Manual installation isn't foolproof and it is hard to guarantee uniform installation procedures when software is installed manually. It may also be worth the effort if your solution can be reused to deal with other systems maintenance issues down the road or in other server clusters in your company.

On the other hand, as boring as the idea of manually installing and compiling on each machine may be, it may in fact be the most practical for your organization.

Best, beth