How 'bad' is replacing /usr/bin/perl with /usr/local/bin/perl on CentOS?

ANSWERED: Basically, it can be done with no major side-effects if you compiled your own perl and you did it the same way your OS did. While it isn't a recommended practice, I've been able to run like this for more then a month. I would conclude it is relatively safe to do if you know what you are doing.

We came to the conclusion at work today that we needed to upgrade perl to 5.10.0 CentOS 5.x comes with perl 5.8.8.

We determined that the effort involved in maintaining scripts with #!/usr/bin/perl was futile.

According to some install stuff on CPAN and other places, it isn't a 'good' idea to replace the OS's version of perl. I already updated the link in /usr/bin/. So my question is, how bad is it really to replace /usr/bin/perl?

I've not noticed any adverse effects in our systems yet, but I'm prepared to correct the link (back to 5.8.8) as soon as there is a problem.

I'm worried that there may be some modules in the CentOS开发者_运维技巧 standard distro that aren't included in CPAN's source 5.10.0. I'm still trying to figure out what those modules might be.

Thanks in advance.

In my experience, the best practice is to compile your entire stack (Perl, Apache, ImageMagick, ...) from source yourself. That gives you complete control over which versions of everything are used and when everything gets upgraded.

Replacing /usr/bin/perl with one you compiled is a crap shoot. The OS might be using /usr/bin/perl as part of its maintenance or init scripts so changing it could brick your server or cause strange failures.

So ignore the system Perl, build your own, and fix your scripts to refer to your version of Perl.

Generally newer versions of Perl5 attempt to maintain backward compatibility with older versions. But that's not 100% assured. For example, a script that depends on an undefined behavior in Perl 5.8.8 (which shouldn't happen but sometimes does), that behavior may be different under 5.10.0. Nevertheless, it's usually fairly safe to assume that a script written for Perl 5.8.8 will run under 5.10.0 assuming there are no other factors involved.

But there usually are other factors (modules, byte compatibility for XS code, and so on). The list of possible gotchas is huge. That doesn't mean that any one of them will snag you on this go-around, but there is potential for problems.

If you've already got an upgraded Perl in /usr/local/bin, go ahead and use it. But don't dismantle or upgrade the old /usr/bin/ version. It's only a small chunk of hard drive (very small by today's standards).

By the way, a lot of people speak highly of perlbrew (App::Perlbrew on CPAN) as a tool to help maintain multiple versions of Perl.

Well, if you do decide to change the location of where Perl is installed, that is completely up to you and where you prefer it to be. But, keep in mind that any scripts that exist with a shebang line pointing to #!/usr/bin/perl will possibly break.

My recommendation would be that after you have installed it, create a soft link in /usr/bin/perl pointing to the executable for the new version of Perl that you installed. Just a thought. Its a work around to avoid breaking anything.

Creating the link above would certainly help to avoid the possibility of 'bricking your server' as @Mu pointed out.

Regards,

Jeff