回答：基本上，如果您编译自己的perl并且您的操作方式与操作系统相同，那么它可以在没有重大副作用的情况下完成。虽然这不是推荐的做法，但我已经能够这样运行一个多月了。如果你知道你在做什么，我会得出结论是相对安全的。
我们今天在工作中得出结论，我们需要将perl升级到5.10.0 CentOS 5.x附带perl 5.8.8。
我们确定使用#!/usr/bin/perl维护脚本所涉及的工作是徒劳的。
根据CPAN和其他地方的一些安装内容，更换操作系统版本的perl并不是一个“好”的想法。我已经更新了/usr/bin/中的链接。所以我的问题是，取代/usr/bin/perl有多糟糕？
我还没有注意到我们的系统有任何不良影响，但是我一旦出现问题就准备纠正链接（回到5.8.8）。
我担心CentOS标准发行版中可能会有一些模块没有包含在CPAN的源5.10.0中。我还在试图找出那些模块可能是什么。
提前致谢。
答案 0 :(得分：5)
根据我的经验，最佳做法是自己编译整个堆栈（Perl，Apache，ImageMagick，...）。这使您可以完全控制所有版本的使用以及所有内容的升级。
用你编译的/usr/bin/perl取代/usr/bin/perl是一个废话。操作系统可能正在使用init作为其维护或{{1}}脚本的一部分，因此更改它可能会破坏您的服务器或导致奇怪的故障。
因此，请忽略系统Perl，构建您自己的系统，并修复脚本以引用您的Perl版本。
答案 1 :(得分：4)
通常较新版本的Perl5试图保持与旧版本的向后兼容性。但这并非100％保证。例如，一个依赖于Perl 5.8.8中未定义行为的脚本（不应该发生但有时会发生），该行为在5.10.0下可能会有所不同。尽管如此，假设没有其他因素，假设为Perl 5.8.8编写的脚本将在5.10.0下运行通常是相当安全的。
但通常还有其他因素（模块，XS代码的字节兼容性等）。可能陷阱的清单是巨大的。这并不意味着他们中的任何一个人都会在这次复飞中遇到你，但是有可能出现问题。
如果您已经在/ usr / local / bin中安装了升级的Perl，请继续使用它。但是不要拆除或升级旧的/ usr / bin /版本。它只是一小块硬盘（按今天的标准来说非常小）。
顺便说一下，很多人都非常赞赏perlbrew（App :: Perlbrew on CPAN）作为帮助维护Perl的多个版本的工具。
答案 2 :(得分：3)
好吧，如果您决定更改Perl的安装位置，那完全取决于您和您喜欢的位置。但是，请记住，任何存在指向＃！/ usr / bin / perl的shebang行的脚本都可能会中断。
我的建议是，在安装它之后，在/ usr / bin / perl中创建一个指向您安装的新版Perl的可执行文件的软链接。只是一个想法。它是一个避免破坏任何东西的工作。
创建上面的链接肯定有助于避免像@Mu指出的那样“破坏你的服务器”的可能性。
此致
杰夫