My condolences... been there done that. I've no experience with Anthill so I can't comment there.
The official answer is: "It depends." The dependencies here are (and not limited to)
I'll tell a quick "war story" here as a way of illustrating one way of accomplishing this in a worst case scenario BUT with some handy tools that helped out a bit.
I used to be in charge of being the Perl "librarian" for a very large financial firm on a global scale. The platforms I supported ran the gamut of SunOS 4.x to Solaris 5.[2-6] and Linux Redhat, Debian and Suse. The good news was we used AFS (Andrew File System) with multiple replica nodes around the globe. Perl itself was not installed on a system at build time but a symbolic link for Perl and its friends and pieces were installed instead pointing to the right place in AFS.
We had a "build farm" with a battery of scripts that would build and install a CPAN module into AFS and then release to AFS after a successful build and test. There was a home grown database that kept a list of modules that had been "blessed" to be provided for distribution.
Not only did we have to support a wide variety of platforms, but due to developer/app support team concerns we supported multiple versions of Perl including Perl4 (yuck!!) and which Perl a system got was driven by the host build process.
All this was made possible by a philosophy of not installing anything on a host's local hard drive except the OS itself where practical.
I didn't always agree with all of this but it worked.
Another way I'd consider for solving this is setting up your own packaging scheme and setting up a process for installation and update of your own Perl package which would include the modules you want to distribute in your environment.
In reply to Re: Anthill to manage perl installations
by blue_cowdawg
in thread Anthill to manage perl installations
by jpross81
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |