Keeping things upto date

builder has asked for the wisdom of the Perl Monks concerning the following question:

I have recently updated a CentOS 6 server. On a recommendation, I used the "Continuous Release" yum repository to get a few security updates. Unfortunately, this broke a couple perl based web applications running on that server. The author of those perl applications thinks that some system library has been changed, probably related to ssl. (I know, I'm long winded ;-)).

I need a way to rebuild and reinstall all of the CPAN modules that were built using the old libraries. I guess I could wander though the .cpan/build directory structure hoping that a "make clean/all/install", etc would catch it, but I would hope that there is a more productive way to get it done.

Suggestions?

Comment on Keeping things upto date

Replies are listed 'Best First'.
Re: Keeping things upto date by Eliya (Vicar) on Dec 06, 2011 at 23:35 UTC
The author of those perl applications thinks that some system library has been changed, probably related to ssl. I'm not aware of any tool that would automagically rebuild/update just the modules required, resolve any system library version incompatibilities etc. There are a few modules (like Module::ScanDeps) that might help with finding dependencies of a particular application, but they typically don't work too well with respect to secondary dependencies on system libraries (which - from what you're saying - appears to be your problem here). So I would start by taking a closer look at the error message. It will most likely tell you what failed loading — at least the first module. (Even if the applications broke more subtly, the exact error behavior will most likely still provide useful hints.) Then rebuild/reinstall that module the same way it was installed originally — you mentioned cpan (as opposed to the distro's package manager), so I figure that's how the modules were installed. Then rinse and repeat until you get no further module loading errors.	[reply]
Re: Keeping things upto date by tobyink (Canon) on Dec 06, 2011 at 23:23 UTC
cpan-outdated	[reply]
Re^2: Keeping things upto date by Eliya (Vicar) on Dec 07, 2011 at 00:26 UTC
I'm not sure if upgrading modules to the newest versions available would be a good idea here (it might cause even further breakage and incompatibilities with the existing applications). But CPAN's recompile might be worth a try instead...	[reply]
Re: Keeping things upto date by scorpio17 (Canon) on Dec 07, 2011 at 18:45 UTC
What you need to do is install all the CPAN modules required by the webapps to a local lib directory, then make sure the apps search the local lib first, when looking for modules. This will help make the apps less dependent on the system perl. And if you need to distribute the apps to another server, you can just tar up the local lib directory and copy it directly, instead of having to reinstall everything via cpan.	[reply]
Re^2: Keeping things upto date by Eliya (Vicar) on Dec 07, 2011 at 20:50 UTC
Although not dependent on the system Perl, this approach essentially has the same problems with XS modules that are linked against system libraries. For example, take Net::SSLeay. The XS shared lib `".../Net/SSLeay/SSLeay.so"` that directly belongs to the module is typically in turn linked against system libraries, such as `/usr/lib/libssl.so.0.9.8`, which implement the real functionality (the `SSLeay.so` is just the binding/wrapper). As those system libs are located externally of the local lib tree that you packaged up, you'll run into exactly the same problems, in case some system upgrade should've messed with those libs... The only way around such issues is to either link the binding statically against a `".a"` version of the respective system libs (suitable for advanced users only — in any case definitely not the default) package up the (tested) system libs together with the Perl stuff, and hard-code the dynamic library search path (to your local lib dir) into the shared object of the XS binding (also not the default) as (2), but mess with LD_LIBRARY_PATH, or similar, at runtime	[reply] [d/l] [select]