我如何知道机器上的特定 Perl 安装最初提供了哪些模块？答案

【问题标题】：How can I tell what modules were originally provided with the specific Perl installation on a machine?我如何知道机器上的特定 Perl 安装最初提供了哪些模块？
【发布时间】：2010-01-18 11:11:15
【问题描述】：

我如何知道机器上的特定 Perl 安装最初提供了哪些模块？

（这不是的副本： How can I tell if a Perl module is core or part of the standard install? （“我如何判断 Perl 模块是核心还是标准安装的一部分？”） - 这实际上是一个衍生问题）

我正在寻找安装最初附带的内容、作为该安装的一部分提供的模块、内置的内容。不是从那以后安装的。

我希望它适用于任何 Perl 版本。

我希望能够做到这一点：

在安装的机器上使用 Perl 程序本身/命令中的脚本。因此，为此，我将依靠安装以某种形式记录它最初的内容。
在我安装之前下载的包。询问它有哪些模块。

我想这样做的原因是：

我想知道在编写软件以在安装了 Perl 的机器上运行时，哪些模块可以作为默认模块，以及我需要添加哪些不是默认模块
如果我保留原始安装程序映像/包或知道如何再次在线获取确切的内容，那么我可以为多台机器进行可重复的一致 Perl 安装，并且知道哪些模块将出现，哪些模块不会出现。
我的 Perl 软件将有一个定义明确的部署过程，因为它很容易准确地定义软件所需的内容
由于我所在组织的政策，我可能无法轻松地更新/升级 Perl 版本（就是这样，我不想就此展开讨论）。这样的政策是有道理的，因为升级到新软件总是存在超过收益的风险。因此，开发者需要知道他们可以期待什么。

我问这个问题的原因是，对于任何 Perl 版本，似乎都没有一种自动方式来找出总体标准安装，定义您可以期望在您的机器上的默认安装中出现哪些模块 -见问题： How can I tell if a Perl module is core or part of the standard install? （“如何判断 Perl 模块是核心还是标准安装的一部分？”）

不能依赖 Perl 版本来告诉您哪些模块存在或不存在。当然，网上可能有文档告诉你。但我需要一种自动方式在我下载/安装的版本上执行此操作。即使是相同的 Perl 版本在不同的 Linux/Unix 发行版上也可能不同。

【问题讨论】：

您是否考虑过使用 PAR 或 ShipWright？
您已经有了这个非常笼统的问题的答案。一个有答案的更好的问题是“我如何知道 Debian 附带了哪些 Perl 模块？”
@brian d foy：当然是 Debian，但我也需要能够在其他各种发行版上执行此操作，正如评论说这是从 (stackoverflow.com/questions/2049735) 衍生出来的问题/跨度>
@Alexandr Ciornii：谢谢-我会调查 ShipWright，到目前为止我发现：search.cpan.org/~sunnavy/Shipwright-2.4.4 和 PAR，我发现：par.perl.org/wiki/Main_Page
@Rob：是的，我知道您希望在不同的平台上使用它，但是每个平台（以及该平台的每个版本）都会有不同的答案。除非您缩小问题范围，否则您不会得到比现有答案更好的答案。

标签： perl deployment perl-module

【解决方案1】：

一般来说你不能。如果您接受这一点并从不同的角度解决问题，您的挫败感就会少得多。 Module::CoreList 提供了一个列表，列出了所有安装中应该包含的最低限度，但供应商不需要遵守这一点，并且大多数发行版都包含许多不属于核心的模块。除非为每个发行版的哪个版本中包含的内容建立自己的数据库——这是一项艰巨的任务——否则希望不大。请注意，即使是随发行版提供的模块，安装的版本也可能不同。

我可以看到几种不同的方法来解决这个问题：

如果您在开发时就知道您的目标（例如，特定的 ActivePerl 版本），您可以根据它做出决定。
对于一般情况，像模块一样部署您的应用程序并指定依赖关系。例如使用Module::Build 并在 requires Build.pl 脚本的部分。 cpan shell 可以跟随并解析自动依赖。
如果您想完全回避这个问题，请使用PAR 和Par::Packer 创建独立的部署包。

【讨论】：

谢谢 +1 - 这看起来不错。我会在有更多时间并跟进更多想法/决定时进行更多研究。
我接受了这个答案，因为它提供了最广泛的答案，鼓励我思考这个问题。也感谢 @gbacon 和 +1。

【解决方案2】：

对于 Debian 或 Ubuntu，您可以使用

$ dpkg --listfiles perl | grep '\.pm$'

对于红帽：

$ rpm -ql perl | grep '\.pm$'

【讨论】：

在 openSUSE 上：> rpm -ql perl perl-doc|grep '\.pm$'
这些显示您现在拥有的文件，而不是原始安装，不是吗？
@gbacon 谢谢。我会看看这些做什么，稍后再回来看看是否对@brian d foy 的问题和更多想法有任何反馈。
@brian：不。我不能代表 Redhat，但在 Debian 中，dpkg -L|--listfiles package 显示与仅该特定软件包相关联的文件。而在 Debian 中，如果您安装其他模块，它们来自其他软件包。所以，dpkg -L perl 将只显示基本 Perl 安装中的文件。
+1 为您的回答@gbacon 我希望结果列表用于“原始安装”。

【解决方案3】：

我正在寻找随原来安装，什么模块作为其中的一部分提供安装，内置什么。不是从那以后安装了什么。

也许对于非核心模块，您可以解析 perllocal.pod，将与 Perl 安装本身一起安装的初始批次模块与基于日期的后续模块分开。您正在寻找以下行：

=head2 Wed Apr 30 15:40:38 2008: C<Module> L<URI|URI>

所以前几个大概是那些用 Perl 本身安装的并且应该有相同的日期（当然不是相同的时间）。那些安装时间相差 24 小时或更长时间的将是您所寻找的。p>

不确定核心模块，因为我认为您在链接到的上一个问题中得到的答案是令人满意的，但显然您不这么认为。可能我错过了什么:)

干杯，报价

【讨论】：

perllocal.pod 总是会失败。它只适用于那些关心更新它的工具，而不适用于用户手工做的好事情。
@solid-state：“不确定核心模块，因为在我看来，您在链接到的上一个问题中得到的答案是令人满意的” - 我同意 stackoverflow.com/questions/2049735 中的答案很好（谢谢大家）但解决方案只处理相对较新的 Perl 版本，我认为我将不得不接受 - 这更多地与 Perl 的方式有关，而不是答案海报的能力！ @Michael Carman 也将上述观点作为他回答的一部分。
@Rob：解决方案可以处理过去 15 年中发布的大多数 Perls。这不是 Perl 的问题。您一直忽略这样一个事实，即这是重新包装商的一个问题，没有人可以阻止他们分发的产品的分解和分裂。