On Sat, Feb 23, 2013 at 2:32 PM, Nico Kadel-Garcia <[log in to unmask]> wrote:
> On Sat, Feb 23, 2013 at 7:46 AM, Natxo Asenjo <[log in to unmask]> wrote:
>> On Fri, Feb 22, 2013 at 5:24 PM, Nico Kadel-Garcia <[log in to unmask]> wrote:

>> 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.

never came accross that (lucky me!), but you can always create your
own mini-cpan and install the modules you need from there or ask
cpan(m) nicely to do it for you.

See http://stackoverflow.com/questions/260593/how-can-i-install-a-specific-version-of-a-perl-module

>>> 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 system.

Well, this is part of the job ;-) ; there is life outside the official
repositories and although it would be lovely to have everything in
nicely packaged in actively maintained repos, that is not always
feasible. So yes, keeping a software repository for the company and
testing it is part of our job (this was too in 'The practice of system
and network administration' by Limoncelli et al, by the way).

>> 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.

clean up is just a question of removing files from the source. We
leave the system Perl alone, so there are no collisions.

In the hypothetical event two apps had conflicting modules, then we
would have use the perlbrew lib facility which takes care of all that
(see http://perlbrew.pl/Install-a-sitecustomize.pl-file-with-perlbrew.html).

>> 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.

what you are describing is the reason we do not touch the system's
Perl and why before deploying something the requirements must be very
specific.

Usually most times the troubles will be the other way round: our
favourite linux vendor distributes a hopelessly outdated version of
Perl. They know it, they don't care. So developers have worked around
this and their solutions are clean, easy and unobtrusive. I cannot
blame them.

I know this used to be a huge problem. I have had more than enough
problems myself getting all the modules to get Request Tracker up and
running, for instance. But now it just works out of the tarball. And
that is priceless.

Any way, this is way off topic now.

-- 
groet,
natxo