获取 Gentoo！

GLEP 44：Manifest2 格式

作者 Marius Mauch <[email protected]>
类型 标准跟踪
状态 已替换
版本 1
创建日期 2005-12-04
最后修改日期 2022-07-08
发布历史 2005-12-06, 2006-01-23, 2006-09-03
被替换为 74
GLEP 源码 glep-0044.rst

摘要

本 GLEP 提出了一种新的 Portage Manifest 和摘要文件系统格式，通过将这两种文件类型统一为一种，以改进 Portage 树的功能和非功能方面。

动机

请参阅 [1] 以获取一般概述。本提案的主要长期目标是

  • 从树中移除微小的摘要文件。它们是一个主要的问题，因为在典型的配置中，它们浪费了大量的磁盘空间，并且在emerge --sync期间所有摘要文件的名称的简单传输需要大量带宽。
  • 当使用多个哈希函数时减少冗余
  • 如果一个文件记录在多个摘要文件中，则消除校验和冲突的可能性
  • 文件类型之间的差异，以获得更灵活的验证系统

规范

新的 Manifest 格式将以以下方式更改现有格式

  • 添加文件类型说明符，目前计划使用以下类型：

    • AUX用于 ebuild 直接使用的文件（例如补丁或初始化脚本），位于files/子目录下
    • EBUILD用于所有 ebuild
    • MISC用于 ebuild 不直接使用的文件，例如ChangeLog或metadata.xml文件
    • DIST用于 ebuild 的SRC_URI变量中记录的发行版压缩包，这些文件以前记录在摘要文件中

    未来的 portage 改进可能会扩展此列表（例如与 eclass 或配置文件相关的类型）

  • 每个文件只保留一行信息，而不是每种文件和校验和类型都有一行

  • 移除files/子目录下

中的独立摘要文件

<filetype> <filename> <filesize> <chksumtype1> <chksum1> ... <chksumtypen> <chksumn>

新格式中的每一行具有以下格式：

但是，这些条目将存储在现有的 Manifest 文件中。

兼容性条目

为了与现有 portage 版本保持兼容性，在引入 Manifest2 格式后需要一个过渡期，在此期间，portage 不仅必须能够使用现有的 Manifest 和摘要文件，还必须生成它们以及新条目。幸运的是，这可以通过简单地在 Manifest 文件中混合使用旧样式和新样式的条目来实现，现有 portage 版本将简单地忽略新样式的条目。对于摘要文件，没有新的条目需要关注。

范围

需要注意的是，本提案只涉及摘要和 Manifest 系统格式的更改。

它不会扩展其范围以涵盖 eclass、配置文件或 Manifest 系统未涵盖的任何其他内容，也不会以任何方式影响 Manifest 签名工作（尽管两者的实现可能会耦合）。

此外，虽然多个哈希函数将随着提议的实现成为标准，但它们不是此格式的特定功能 [2]。

哈希数量

虽然为每个文件使用多个哈希是本提案的主要功能，但我们必须确保列出的哈希数量受到限制，以避免 Manifest 大小激增，这将抵消本提案的主要好处（减少树的大小）。因此，生成的哈希数量将限制为三种不同的哈希函数。但是，为了兼容性，我们必须依赖至少一个哈希函数始终存在，本提案建议为此目的使用 SHA1（因为它被认为比 MD5 更安全，并且目前只有 SHA1 和 MD5 在 python 中直接可用，此外，MD5 在兼容性方面没有任何优势）。

基本原理

提案的主要目标已在 动机 中列出，此处解释了它们为什么是改进以及提议的格式将如何实现它们。

移除摘要文件

不使用为 portage 树“调整”的文件系统的普通用户正在使用当前系统浪费几十到几百兆字节的磁盘空间，这主要是由摘要文件造成的。这是由于大多数文件系统中存在的具有 4 千字节标准块大小的文件系统开销造成的，而大多数摘要文件的大小都小于 1 千字节，因此这导致每个摘要文件大约浪费了 3 千字节（可能更多）。在撰写本文时，该树大约包含 22000 个摘要文件，因此摘要文件造成的整体浪费估计约为 70-100 兆字节。此外，假设这也会减少 Manifest 文件浪费的磁盘空间，因为它们现在包含更多内容，但尚未对此进行验证。

通过将摘要文件与 Manifest 统一，这些微小文件将被消除（从长远来看），从而将明显的树大小减少约 20%，这对用户和 Gentoo 基础设施都有利。

减少冗余

当使用当前系统使用多个哈希时，文件名和文件大小会为使用的每种校验和类型重复，因为每个校验和都是独立的。但是，这不会添加任何功能，因此是无用的，因此新格式删除了此冗余。目前，这是一个理论上的改进，因为只使用了一种哈希函数，但预计很快就会改变（参见 [2]）。

消除校验和冲突

当前系统理论上允许DIST类型文件以不同的大小和/或校验和记录在多个摘要文件中。在这种情况下，软件包的一个版本将报告校验和冲突，而另一个版本则不会。这可能会在用户中造成混淆和不确定性。到目前为止，尚未观察到这种情况，但无法排除现有系统。由于新格式每个文件只列出一次，因此这将不再可能。

灵活的验证系统

现在 portage 在使用软件包的任何文件之前验证 Manifest 中列出的每个文件的校验和，并在使用该 ebuild 之前验证所有DISTebuild 的文件。在许多情况下，这是不必要的

  • 在“depend”阶段（生成 ebuild 元数据时），只使用EBUILD类型文件，因此无需验证其他类型。理论上，ebuild 可以在此阶段包含其他文件，例如AUX类型文件，但这将是重大的 QA 违规，不应该发生，因此此处可以忽略。它也不是安全问题，因为在解析 ebuild 之前会对其进行验证，因此每个操作都会显示出来。
  • 通常，MISC类型文件不需要验证，因为它们仅在非常特定的情况下使用，不会执行（最多只解析）并且不会影响软件包构建过程。
  • 类型为DIST的文件只需要在获取后和解包前直接验证（这通常是一个步骤），而不需要每次使用其关联的 ebuild 时都进行验证。

向后兼容性

切换 Manifest 系统是一项需要很长过渡期的任务，就像大多数影响 portage 和树的更改一样。在这种情况下，实现将分几个阶段推出

  1. 在 portage 中添加对验证 Manifest2 条目的支持
  2. 除了当前系统之外，还可以启用生成 Manifest2 条目
  3. 在emerge --sync期间忽略摘要以获得客户端大小优势。如果预计后续步骤很快执行，则可以省略此步骤。
  4. 禁用当前系统的条目生成
  5. 从树中删除当前系统的所有痕迹（服务器端）

每个步骤都有其自身的问题。虽然 1) 和 2) 可以毫无兼容性问题地实现，但所有后续步骤都会产生重大影响

  • 步骤 3) 只能在整个树准备好 Manifest2 时实现（理想情况下，实际上，要求将更像是 95% 的覆盖率，并期望对于剩余的 5%，要么在步骤 3) 完成后提交错误报告，要么在步骤 5) 中更新它们）。
  • 步骤 4) 和 5) 将使所有不具备 Manifest2 支持的 portage 版本基本无用（用户必须在能够合并每个软件包之前重新生成每个软件包的摘要和 Manifest），因此这需要几乎 100% 的用户群覆盖使用支持 Manifest2 的 portage 版本（并且步骤 1) 完全实现）。

另一个问题是一些步骤影响不同的目标

  • 步骤 1) 和 3) 以用户使用的 portage 版本为目标
  • 步骤 2) 和 4) 以开发人员使用的 portage 版本为目标
  • 步骤 5) 以 cvs 服务器上的 portage 树为目标

虽然让所有开发人员都使用新的 portage 版本相对容易，但对于用户来说，这实际上是不可能的，因为有些人不会定期更新他们的系统。虽然六个月可能足以达到 95% 的覆盖率，但估计需要一年才能达到几乎完全的覆盖率。所有时间都相对于兼容 portage 版本的稳定标记而言。

此处未提供实现时间表，因为它高度依赖于每个步骤的完成情况。

总之，可以这么说，由于上述兼容性问题，虽然完整转换需要一年多的时间才能完成，但一旦步骤 2) 完成，就可以选择性地使用该系统的一些好处。

其他问题

对基础设施的影响

虽然本提案的一个长期目标是减少树的大小，从而使 Gentoo 基础设施更轻松，但这只有在实施完全推出后才会生效。然而，在此期间，由于两种格式都保留了校验和，因此它会增加树的大小。无法给出关于增加程度的可使用估计，因为它取决于许多变量，例如确切的实施时间表、开发人员中 Manifest2 兼容 Portage 版本的传播或树的更新率。有人建议可以一步一步地批量转换未经 GPG 签名的 Manifest 文件，这当然可以提供帮助，但只能在一定程度上提供帮助（根据最近的研究[3]，树中大约 40% 的 Manifest 文件已签名，但此数字尚未经过验证）。

参考实现

Manifest2 验证和部分生成的原型实现的补丁已发布在[4]，在考虑将其包含到 Portage 中之前，它将被重新修改。但是，它表明添加验证支持非常简单，但生成有点棘手，因此将在稍后实施。

选项

一些事项已考虑用于此 GLEP，但由于各种原因尚未成为提案的一部分。

  • 时间戳字段：作者已考虑为每个条目添加时间戳字段，以列出创建该条目的时间。但是到目前为止，尚未找到此类功能的实际用途。
  • 将大小字段转换为校验和：另一个想法是像处理其他任何校验和一样对待大小字段。但到目前为止，还没有发现此方法的真正好处（除了稍微更模块化的实现之外），而它却存在一些缺点：首先，与校验和不同，大小字段对于所有文件都是绝对必需的。DIST文件，它还会通过添加一个稍微增加每个条目的长度。SIZE关键字。
  • 删除MISC类型：有人建议完全删除类型为MISC的条目。这将导致空间略微减少（不太可能释放任何块），但完全删除了检查这些文件完整性的能力。虽然它们不会直接影响 Portage 或软件包，但它们可能包含用户可用的信息，因此作者认为至少应保留完整性检查的选项。

致谢

感谢以下人员对本 GLEP 的投入或与之相关的内容（即使他们可能不知道）：Ned Ludd (solar)、Brian Harring (ferringb)、Jason Stubbs (jstubbs)、Robin H. Johnson (robbat2)、Aron Griffis (agriffis)

还要感谢 Nicholas Jones (carpaski) 使当前的 Manifest 系统足够健壮，能够处理此更改而不会出现太多过渡问题。

参考文献

[1]Marius Mauch。“摘要重组和增强”。gentoo-dev 邮件列表，2004 年 10 月 8 日，消息 ID [email protected]，https://archives.gentoo.org/gentoo-dev/message/4afc65da379b8570a4cec654976da862
[2](1, 2) Marius Mauch。“Portage 中的多哈希支持 - 状态”。gentoo-dev 邮件列表，2005 年 11 月 24 日，消息 ID [email protected]，https://archives.gentoo.org/gentoo-dev/message/f97ff5732872ffe44ef05627b7a19cc1
[3]Robin H. Johnson。“Gentoo 密钥签名实践和官方 Gentoo 密钥环”。gentoo-core 邮件列表，2005 年 11 月 17 日，消息 ID [email protected]
[4]https://archives.gentoo.org/gentoo-portage-dev/message/f2b5be6629510343bd50418429912b1d