On Sat, Feb 23, 2013 at 7:46 AM, Natxo Asenjo <[email protected]> wrote: > On Fri, Feb 22, 2013 at 5:24 PM, Nico Kadel-Garcia <[email protected]> wrote:
>> As long as you package the modules, you can get away with this. One of >> the painful difficulties comes when people put "cpan build Foo::bar" >> for the Foo:::Bar module to enable features on their deployed systems, >> built right into their config scripts or testing tools or instlalers, >> and wind up displacing system versions of core utilities. This can, >> and has, included accidentally replacing Perl itself at various times >> to get various updated modules. > > yes, people seem to never have heard of local::lib and get themselves > in terrible troubles ;-) *Tell* me about it. I spent a great deal of time a few years back backporting Apache 1.3 to one of the moral equivalents of Scientific Linux 4, because the oroginal software relied on the old mod_perl package. *dozens* of dependencies. >> Fortunately, for SL and other upstream vendor based modules, it's >> often possible to find them in 3rdparty repositories, especially loo, >> in Fedora for backporting, or to use tools like "cpan2rpm" or >> "cpanspec" to build RPM's for them which you can deploy in an internal >> yum repository or for direct installation via cfengine or puppet. >> similar techniques work well for PHP and Ruby modules as well. >> >> I actually publish a whole stack of these over at >> https://github.com/nkadel/. And i'm happy to show other people how to >> set up build environments for that. > > it's cool to see what you have done, but really, these days building > custom Perls and deploying them side by side system Perl is a very > easy: perlbrew, cpanminus, cpan-outdated. You get the best of both > worlds. New modern Perl goodies for modern times, legacy Perl for > older enterprise systems. It can get..... awkward. You hve to essentially mantain a separate toolchain, and lose the dependency tracking and version tracking that you get with RPM or any sane package management sysstem. > We deploy several Perls to our environments and adding new modules is > just a cpanm away in one place, the changes get picked up and are > distributed to the hosts. And *that* is exactly the problem. Deployment is easy. Cleanup of old components, especially as different versions of different packages pick up the same module names? Not so easy. > Works a treat. Until it doesn't, which I'm afraid I've encountered headlong. The problem isn't making your own, local toolchains, it's the hidden module dependencies. I encountered this with mod_perl some years back: a project needed to use an older mod_perl, and building the toolchain from CPAN led to circular dependencies each calling the most recent version of the other components, which depended on other recent components, which depended on a more recent version of mod_perl. Hilariity ensued. I had to build RPM's for *each individual module", rename them from "perl-foo-bar" to "project-perl-foo-bar" to get them out of the yum update chain, or I'd have had to rewrite all the original source code to do what you originally suggested: look in a locally managed directory, first.
