Please stop doing this. At the very least, do it over HTTPS.
If you're running any form of Unix, it's very likely that you already have a package management system. It's also likely that system has more features, and is better designed from a management and consistency perspective than any one of CPAN and it's descendants (gem, cabal, etc.).
A much better solution - either make your own packages, or use a tool like FPM (https://github.com/jordansissel/fpm) to make native packages, then deploy the result as you would any other package.
I hope for an era when running CPAN or gem interacts with the package manager, building a real OS-level package and installing/deploying it, rather than the current "you need to run this script incantation on every production machine, oh, and you need the whole toolchain too" idiocy.
Additionally, there's the problem of perl (python as well for the last decade) being used as glue for many OS-level tools. Have you ever tried replacing the packaged Perl on a n RHEL box? It's not fun. Also, since it's relied on by so much within the distro, the chances they are going to go through the trouble of updating the version and risk problems is very small. On enterprise distros, you are essentially stuck with an out of date Perl before the distro ships, and stuck with it for the long support lifetime.
This is frustrating to the perl community, as anything that requires "new" features faces limited adoption as a significant portion of the community can't run those versions.
That's not to say that packaging perl isn't the way to go. I believe in many cases it is. I also think it depends on your targets. Three webservers does not make the same argument as a farm of boxes. Even so, the ability to easily test and iterate in your dev environments, before committing resources to building packages and pushing them to QA, is a good thing.
Edit: Changed redundant "additionally" to "also" so it wouldn't bother me anymore. :)
Useful languages will be used.
Used languages will evolve.
Evolution may introduce problems with code written to an older version.
People that rely on older code will have some resistance to newer versions.
A natural friction will arise between those who wish stability in order to maintain, and those who which change in order to evolve.
IMHO if nobody cares about breaking older stuff, that just means that nothing useful has been written yet.
Sorry, no thanks.
Thanks for the FPM-link, that looks interesting for packaging my own software :)
I do like the "isolated" package management these systems offer, and would like to see a good way for user-level packaging to be managed in a more universal way. It's extremely useful to be able to deploy multiple isolated environments, with conflicting dependencies, on the same server and not affect the system libraries in any way.
Say I need libfoo1.1 that conflicts with the system version for project A, and when related project B rolls around, it needs libfoo2.0 in the same system. Do I build a series of _project_A.deb and _project_B.deb packages, with separate install prefixes, and rebuild their associated dependencies in turn?
Large deployments are often very complex systems, and being able to decouple individual environments is a huge improvement.
The hot-new-scripting-language community and top-two-or-three-linux-distro communities just never seem to get along well enough to eliminate this needless layer of duplication and complexity. IMHO its a lot more about fiefdoms and autonomy than technical considerations.
At the same time, I've worked as an application developer as well, and in those circumstances I generally want the latest versions libraries and interpreters. Since I'll be writing all the code expected to run with them, stability is less important. I can work around bugs and incompatibilities myself. Generally though, I need to make sure that my application interpreter and libraries don't interfere with system equivalents because that is a nightmare. So a secondary package system makes sense in this case.
What I would like ideally, is a OS package manager which is capable of handling multiple versions of a programming language gracefully and will let me install a development version alongside a system version, as opposed to hacks like rvm.
gem install fpm