我在 Suse Linux 上将 perl 从 perl58 升级到 perl588。看起来即使旧版本存在 Config.pm，新版本安装也会破坏旧版本。而在 HP 和 AIX 等其他操作系统上升级 Perl 确实如此不要打扰旧版本。 例如:perl58 和 perl588 版本存在于文件夹“/usr/standard_perl”中，如下所示:
/usr/standard_perl/perl58 (directory)
/usr/standard_perl/perl588 (directory)
并有指向它的符号链接(symbolic link)。
升级前后链接如下:
之前:
perl58_link -> /usr/standard_perl/perl58
之后:
perl5_link -> /usr/standard_perl/perl588
perl58_link -> /usr/standard_perl/perl588
perl588_link -> /usr/standard_perl/perl588
现在，当我尝试从/usr/standard_perl/perl58/bin 运行简单的“./perl -V”命令时，旧版本提示找不到 Config.pm，即使它在自己的树结构中很好地存在。
是否在 Linux 中，perl 遵循 @INC 的硬编码路径。这种行为仅在 Linux 上观察到。
我很担心我无法投入生产，因为有些脚本一直在为旧版本运行，如果存在这种行为，我需要知道是否可以修复或者这是 Linux 的已知行为。
我不确定这是不是因为现在升级后的旧链接指向了更新的版本，仅仅链接是不够的，需要在 LINUX 上修改更多的东西？
注意: 1.perl模块每个版本单独维护 2.我没有将任何文件与以前的版本混合。 3. 我们希望在生产服务器上运行的所有旧 perl 脚本都不会中断，而是使用最新版本来维护 Perl 版本。 3a.因此需要调整指向最新版本的链接而不是它们自己的版本。
观察: 仅在 Linux 上看到此行为。 值得注意的一点是当我调整旧版本到最新版本的链接时。 @INC 自动更新为最新版本 INC，而不是在 LINUX 中。
我是不是漏掉了什么？
最佳答案
我从未在 Linux 上见过这个问题。我将原始 perl 留在它的位置 (/usr/bin/perl)，并简单地编译我自己的 perl 以安装到/usr/local/bin(或其他)，并且从未见过任何旧版本的破损。
你不说
- 你是怎么得到/usr/standard_perl/perl588(编译的，以 rpm 格式或其他格式给出，预编译的 tarball，...)
- 您在配置编译时使用了哪些选项
您的详细信息也很含糊 - perl58_link、standard_perl 等 - 这究竟在哪里？大多数时候这无关紧要，但有时确实如此。
如果您将链接移回原处，事情会开始起作用吗？如果将整个 5.8.8 树移到其他地方，事情会开始起作用吗？你能从 RPM 或其他任何东西中恢复你的基本 perl 以使其工作吗？ IMO，基本的 perl 工作是最重要的，次要的 perl 总是额外的。 (我对其他核心 unix 工具持相同的看法，例如 shell、awk、sed，甚至 python 或您的发行版用于包管理的任何东西。对于 Java 等非核心工具则不然，但如果我运行 Java 应用程序在生产中，那么我也会在这里说同样的话。)
关于linux - Perl 升级会破坏 Linux 上的旧版本吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/772710/