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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.