But to be fair Perl isn't the only language where I've seen people do this, I've seen PHP, Python, C and Java developers do it to.
Oh the highginks that insued while trying to figure out why a companies web site didn't work on the new web server with what I thought was an identical build, while a developer who had forgotten what they did was standing over my shoulder saying "is it working yet" over and over again. Those happy memories make me smile every time I think of them.
-- Sent from my HP Pre3
On Feb 23, 2013 8:32 AM, Nico Kadel-Garcia <[email protected]> wrote:
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.
