Re: Modules being installed in different directories, causing problems.

[Tanktalus]

That looks awfully similar to my RHEL 6 box...

First off, you're playing with the system perl. Which may be what you want, but I always start with the suggestion not to do that. If you want a custom set of modules, I highly suggest that you use a custom install of perl. It took me a few years to come to this conclusion, but I strongly believe in it now.

Basically, by updating modules such that "/usr/bin/perl" will load a different version of, say, File::Spec, than the distribution vendor expects, you may remove a bug that the vendor is counting on, or introduce a bug that they weren't expecting. And then system apps may fail. While this is an extremely unlikely scenario, if you are running RHEL (as opposed to CentOS), your employer may be counting on that support contract that you may be voiding, or at least making more expensive. If the system has other modules it is relying on, sometimes they break backwards-compatibility, and that runs a higher risk (though usually system tools don't rely on much that might do something like this). All in all, low likelihood, but if it does happen, the repercussions could be anywhere from support headaches to an unbootable system (likely combined with support headaches).

Instead, by having your own copy of perl in, say, /opt/perl/bin, you know that the system tools aren't relying on any modules you might upgrade. The system tools will continue to merrily use outdated modules with exactly the feature/bug set they are expecting, while your users can put #!/opt/perl/bin/perl as their first line and get all the new features they want without impacting the running of the base operating system. This also has some other happy side effects - for example, you can upgrade to a level of perl that still continues to receive security updates (such as perl 5.16 or 5.18), again without impacting anything else. (I actually have a small array of perls installed to /opt/perl/$version, just for testing, and so I don't need to upgrade every app every time I get a new perl.)

Failing that, the next best thing is to use your OS package manager (rpm/yum if you're on RH) to update the modules instead. If your distribution has the updated modules, this means they've allegedly tested the update and everything should work (or it should pull in the newer versions of whatever needed fixing to update that module). If you're really lucky, the new modules you want, such as Path::Tiny, are also available through this method. Then your problem should be solved. Well, other than possibly cleaning up /usr/local/lib64/perl5 and /usr/local/share/perl5.

Hopefully that helps. I know it's not quite your question, but when faced with a similar issue, I've gone with the above, and maybe that will be an option for you, as well.

[moatman]

Thanks for the suggestions, I took your advice and got lucky, it was available in Yum. I am dreading the idea of having to install a second copy with the way things are set now, but I don't see my luck holding out with the all of modules we will need being in the Yum repository...

Eventually I will have to add our own copy, I can definitely see the wisdom in it and was very close to doing it in this last time. It really opened my eyes, I had no idea it was just haphazardly throwing things wherever it pleased, being in full control of installs will be very nice.

Thanks again, and to everyone else who replied as well.