获取 Gentoo！

GLEP 37：虚拟包弃用

作者 Jason Stubbs <jstubbs@gentoo.org>
类型 标准跟踪
状态 延期
版本 1
创建日期 2005-04-30
最后修改日期 2024-07-16
发布历史 2005-04-30, 2006-09-05
GLEP 源码 glep-0037.rst

状态

迄今为止已实现的内容与本 GLEP 中所述内容略有出入。因此，本 GLEP（以其当前形式）已被标记为“延期”。

鸣谢

本 GLEP 中的大多数想法都来自与 Thomas de Grenier de Latour 的讨论。Ciaran McCreesh、Brian Harring 和 Stephen Bennett 也在完善这一想法方面提供了帮助。

摘要

本 GLEP 涵盖了当前虚拟包系统的弊端、使用常规 ebuild 实现虚拟包目的的好处以及使其可行需要支持的内容。

动机

当前的虚拟包系统是分散的；也就是说，除了扫描所有软件包以查看它们提供了什么之外，没有办法找到有关特定虚拟包的信息。也没有办法判断一个 atom 是否是虚拟包 - 是的，可以使用“virtual/”前缀，但它没有被使用，导致了它的滥用。

这意味着 Portage 必须扫描所有已安装的软件包以查找它们提供的虚拟包，配置文件必须为 Portage 可能遇到的每个虚拟包提供默认值，并且 Portage 处理的每个 atom 都必须与虚拟包列表进行检查。不用说，这会导致性能大幅下降。

当前的虚拟包系统还存在其他一些主要缺点。最著名的案例是 virtual/jdk 和 kaffe。Kaffe-1.1.4 实现 Java 1.4 API，但无法满足需要 >=virtual/jdk-1.4 的软件包，因为 kaffe 的版本控制方案不同。（编辑：需要在此处添加更多内容。;)

规范

本 GLEP 建议将虚拟包与常规软件包无异。具体来说，标准虚拟包将包含 DESCRIPTION、KEYWORDS、IUSE 和 RDEPEND 元数据。一个示例如下所示

DESCRIPTION="Java Development Kit 1.4"
KEYWORDS="amd64 hppa ia64 ppc ppc64 sparc x86"
RDEPEND="|| (
             =dev-java/blackdown-jdk-1.4*
             =dev-java/ibm-jdk-bin-1.4*
             =dev-java/jrockit-jdk-bin-1.4*
             =dev-java/kaffe-1.1.4*
             =dev-java/sun-jdk-1.4*
            )"
IUSE=""

但是，在这样做时出现了一些问题。

一致性

目前，即使其他软件包依赖于某个软件包，也很容易将其删除，这会导致当软件包依赖于间接依赖项时出现 emerge 错误。例如，如果 kdelibs 已合并并引入了 qt，然后 qt 被取消合并，则尝试合并 kdebase 可能会失败。由于依赖项始终是间接的，因此对于虚拟包而言，这个问题变得更加严重。

解决此问题的办法是为 Portage 添加完整的依赖项跟踪和验证。如何实现的细节不在本 GLEP 的范围内，但本质上这意味着 Portage 需要强制取消合并另一个软件包依赖的软件包，并且还能够扫描和修复任何损坏的依赖项。

覆盖

配置文件当前指定每个虚拟包的默认提供程序，用户可以使用 /etc/portage/profile/virtuals 覆盖这些默认值。如果虚拟包被常规软件包取代，并且因此能够具有任意复杂的 DEPEND，则当前覆盖默认虚拟包的方法无法扩展以支持此功能。

在查看解决方案之前，让我们看看当前系统是如何工作的。当 Portage 初始化时，它会搜索已安装的软件包以查找可用的虚拟包。然后它搜索配置文件和用户覆盖，并将它们添加到可用提供程序列表中和/或更改提供程序的顺序，以便覆盖在列表中靠前。然后，Portage 将找到的任何虚拟 atom 扩展为使用初始化时确定的顺序的 OR 列表。

为了保持此行为可用，本 GLEP 提出一个名为 package.prefer 的新文件。在其基本形式中，这只是一个按优先级排序的软件包名称列表。Portage 将通过重新排序它处理的任何 OR 列表的 atom 以适应 package.prefer 给出的顺序来使用它。例如，如果 package.prefer 包含“dev-java/kaffe”，则

|| (
    dev-java/blackdown-jdk
    dev-java/sun-jdk
    dev-java/kaffe
   )

将被处理为

|| (
    dev-java/kaffe
    dev-java/blackdown-jdk
    dev-java/sun-jdk
   )

在其基本形式中，package.prefer 已经涵盖了配置文件和用户覆盖。但是，本 GLEP 建议可以使用任何类型的 atom。这将通过检查 OR 列表中的 atom 和首选列表中的 atom 的交集来实现。当找到交集时，两个 atom 都将在子列表中指定，然后将其视为范围依赖项。例如，如果 package.prefer 包含“<=dev-java/sun-jdk-1.4”，则

|| (
    >=dev-java/blackdown-jdk-1.3
    >=dev-java/sun-jdk-1.3
   )

将被处理为

|| (
    (
      <=dev-java/sun-jdk-1.4
      >=dev-java/sun-jdk-1.3
    )
    >=dev-java/blackdown-jdk-1.3
    >=dev-java/sun-jdk-1.3
   )

范围依赖项不在本 GLEP 的范围内。

基本原理

最大的优点是它为用户和开发者提供了更大的功能。在此方案中，虚拟包的灵活性大大提高，并且满足了现有的需求。这也意味着配置文件维护人员无需为每个虚拟包列出默认值。用户可以通过轻松地收集虚拟包提供程序列表以及扩展其控制来选择任何软件包中存在的选择来获益。

Portage 代码也受益于此方案，因为虚拟包将不再需要特殊处理或对基本上相同的功能进行双重实现，例如基于 USE 的 PROVIDES。此方案也更容易优化，这将有利于所有软件包的处理。这也意味着 DEPEND 词汇表中的任何新增内容都可用于虚拟包的定义中。

向后兼容性

兼容性将从使 2.0.51.20 将未知虚拟包视为常规软件包开始。当树被剥离 PROVIDES 和“virtuals”覆盖文件后，这些 Portage 将使用的唯一虚拟包是用户指定的虚拟包和从已安装的软件包中收集的虚拟包。任何未知的虚拟包都将被视为常规软件包，并在树中查找。

下一个主要版本的 Portage (2.1.0) 将支持一致性检查。唯一剩下的问题是用户覆盖。旧方法即使在新样式的虚拟包中也能工作。唯一的区别是，复杂的虚拟包（即安装多个软件包的虚拟包）可能无法令人满意地覆盖。

计划在下一个主要版本的 Portage (2.2.0) 中停止支持当前样式的虚拟包。到时发布时，将编写脚本以从现有的虚拟包系统创建软件包，以及在配置文件中创建适当的 package.prefer 覆盖。