获取 Gentoo！

GLEP 69：文件安装掩码

作者 Michał Górny <mgorny@gentoo.org>
类型 标准跟踪
状态 延期
版本 1
创建 2015-03-29
最后修改 2019-11-07
发布历史 2016-05-20
GLEP 源码 glep-0069.rst

状态

超过 60 天没有进展。由 GLEP 编辑 Michał Górny 于 2017 年 10 月 13 日标记为延期。

摘要

此 GLEP 描述了包管理器的功能，该功能可用于阻止安装某些软件包的文件。它描述了最小的包管理器行为和配置文件数据格式，使符合 GLEP 的包管理器能够有效地支持该功能，并允许开发人员依赖它。

动机

目前，主要有两种过滤软件包安装文件的方法：USE 标志和 INSTALL_MASK。

USE 标志的优点是它们得到干净的支持，因此提供了一种提供选择的高效方法。但是，它们要求每个 ebuild 提供特定的代码路径来处理它们，并且每次值更改都需要重新构建整个软件包 - 这通常比安装未使用的文件的成本更高。它还会导致二进制软件包中的 USE 标志不匹配，使其无法在更广泛的系统上重复使用。

INSTALL_MASK 完全在包管理器（Portage）级别实现，因此不需要特定的 ebuild 支持。它允许根据文件名称或路径对安装的文件进行统一过滤。这些文件仍然包含在二进制软件包中（并在安装二进制软件包时过滤掉），使其能够在使用这些文件和将其过滤掉的系统之间重复使用二进制软件包。但是，当前实现的 INSTALL_MASK 的主要缺点是它设计上相当低级，要求用户明确命名要擦除的路径。此外，它是一个 Portage 特定功能，缺乏适当的规范。

此 GLEP 旨在通过提供一个最小规范来解决 INSTALL_MASK 的缺点，该规范描述了它应该如何得到支持，并扩展当前的 Portage 实现以支持配置文件定义的路径组。这使包管理器能够可靠且以用户友好的方式实现此功能，从而使其能够在整个 Gentoo 中使用。

规范

包管理器实现要求

实现此规范的包管理器必须提供用户配置安装路径过滤的功能。用户必须至少被允许选择配置文件定义的路径组。包管理器必须支持堆叠包含和排除路径规范。

安装文件的过滤应在将安装的软件包合并到文件系统时执行。它不应用于包管理器构建的二进制软件包中包含的文件。但是，包管理器可能会提供一种额外的机制来过滤二进制软件包中包含的文件。此类机制的详细信息不在此规范范围内。

在过滤时，包管理器应将每个安装的文件路径与指定的包含和排除过滤器匹配，以配置的顺序。如果过滤器链导致文件被积极匹配，则包管理器必须表现得好像它没有被软件包安装一样。除了匹配路径组定义中的路径通配符外，匹配指定过滤器的确切方式未指定。

配置文件定义的路径组

每个配置文件都可以指定零个或多个路径组。这些组在可选的install-mask.conf配置文件内的文件。该文件采用分节的键值格式（类似于layout.conf).

每个部分以[name]开始，其中 name 指定定义的组名称，并且必须后跟

  • 一个或多个path键，每个键指定一个要过滤的单个路径。路径指定为fnmatch()通配符，所有与之匹配的路径都将被过滤。如果路径与目录匹配，则递归过滤该目录。启用该组会导致所有包含在其中的路径被过滤；
  • 正好一个description键，指定该组的人类可读描述。
[bash-completion]
path=/usr/share/bash-completion
description=Completions for app-shells/bash and auxiliary files

[locale]
path=/usr/share/locale/*/LC_MESSAGES
description=All localizations

[locale-pl]
path=/usr/share/locale/pl/LC_MESSAGES
description=Localizations for polish language

路径组定义的范围

由于路径组没有直接绑定到 ebuild，因此所有路径组都全局应用。只要提供该组的配置文件已启用（直接启用或作为配置文件继承的结果），用户就可以使用特定组。对未定义组的引用应被视为错误。

子配置文件可以覆盖路径组定义。如果多个配置文件在继承链中定义了相同名称的路径组，则最后定义的路径组适用。如果最后一个定义未定义任何path=键（即为空），它会删除由之前配置文件定义的路径组。

请注意，实现也可以提供覆盖用户配置中路径组的方法。

基本原理

该规范旨在与当前的 Portage 实现最佳匹配，同时使其尽可能灵活并适当地扩展以供用户友好使用。

包含配置文件定义的路径组对于使该功能对用户友好是必要的。它既可以节省用户找出正确路径通配符的时间，又可以提供可能感兴趣的路径的完整参考。对堆叠和排他规范的支持使得能够排除特定的路径子集，例如在过滤掉所有其他本地化时排除特定的语言环境。

该规范还要求掩码仅应用于安装的文件而不是二进制软件包。这样，就可以在具有不同 INSTALL_MASK 值的系统上重复使用二进制软件包。这也使得部署 binhosts 变得更容易，因为用户不必担心意外过滤掉文件。附加条款允许提供额外的机制来过滤二进制软件包中的文件（Portage 中的 PKG_INSTALL_MASK），同时保持基本实现安全。

对指定直接路径的支持是可选的，因为它对于目标来说不是严格必要的。它的所有细节都留给实现定义，包括匹配模式的具体方式，以适应 Portage 中使用的特定匹配方式。

配置文件定义的路径组数据库的文件格式被选择为重用 metadata/layout.conf 的格式。这样可以避免在包管理器中实现另一个格式解析器，同时保持易于阅读和写入。XML 被认为是另一种选择，但对于此规范的需要来说，它显得过于复杂。

最初，路径组是在存储库范围内定义的。但是，这会导致作用域问题 - 特别是，对于尝试定义相同组的多个存储库，尚不清楚哪种行为才是正确的。将组绑定到配置文件更符合全局作用域。它还使得能够将路径组限制到特定的配置文件 - 例如，避免提供systemd在 systemd 配置文件中定义路径组，这样会导致系统无法启动。

向后兼容性

GLEP 明确要求由实现它的包管理器构建的二进制软件包不受影响。因此，二进制软件包保持与未实现此 GLEP 的包管理器的完全兼容性。

GLEP 确实允许当前（2016-05-20）Portage 实现 INSTALL_MASK 和 PKG_INSTALL_MASK 的细节作为实现定义。但是，Portage 并未实现此 GLEP 所需的所有功能。

额外的配置文件将被不兼容的包管理器丢弃，因此不会影响向后兼容性。

参考实现

Portage 中的初始 INSTALL_MASK 支持

截至 2016-05-20，Portage 具有安装掩码支持，该支持不符合此 GLEP。

配置通过两个变量完成： - INSTALL_MASK 过滤安装到系统中的文件， - PKG_INSTALL_MASK 过滤二进制软件包中包含的文件。

这两个变量是独立的；也就是说，可以在将文件安装到活动系统时过滤二进制软件包中的文件。

这两个变量都接受以空格分隔的一组fnmatch()模式。每个模式可以匹配完整路径或文件名。不支持排除；任何与至少一个模式匹配的文件实际上都会被过滤掉，因为它会从相应的安装树中删除。

Portage 的 GLEP 实现

为了在 Portage 中启用对此 GLEP 的支持，准备了三个初始补丁并发送到 Portage

  • portage.package.ebuild.config: Move FEATURES=no* handling there [1],
  • portage.dbapi.vartree: Move INSTALL_MASK handling into merging [2],
  • portage.dbapi.vartree: Support exclusions in INSTALL_MASK [3].

这些补丁替换了使用 bash 和 GNU find 编写的旧 INSTALL_MASK 处理，并使用完整的 Python 基础设施。过滤现在在安装文件时动态完成，因此无需从安装树中物理删除它们。这使得能够添加排除支持。

路径组支持正在进行中。

参考资料

[1]portage.package.ebuild.config: Move FEATURES=no* handling there, Message-ID 20160522065604.10593-2-mgorny@gentoo.org, https://archives.gentoo.org/gentoo-portage-dev/message/bdce65377f162be398230c648d4f9712
[2]portage.dbapi.vartree: Move INSTALL_MASK handling into merging, Message-ID 20160522065604.10593-3-mgorny@gentoo.org, https://archives.gentoo.org/gentoo-portage-dev/message/c9b95dff7be46876d052ca13da675947
[3]portage.dbapi.vartree: Support exclusions in INSTALL_MASK, Message-ID 20160522065604.10593-4-mgorny@gentoo.org, https://archives.gentoo.org/gentoo-portage-dev/message/29e128a9f41122fa0420c1140f7b7f94