获取 Gentoo！

GLEP 9：Gentoo 软件包更新系统

作者 John J. Whitney <jjw@linuxmail.org>
类型 标准跟踪
状态 延迟
版本 1
创建日期 2003-07-19
最后修改日期 2014-01-15
发布历史 2003-07-25
GLEP 源代码 glep-0009.rst

摘要

本文档提出了一种针对 Gentoo Linux 的正式软件包更新系统。Deltup 项目已为此目的而开发。[1]

随着软件包越来越大，冗余数据量也在不断增加。通过补丁更新现有 tarball 是处理源代码更新的自然方式。

动机

此系统将减少镜像负载（可能还会减少镜像大小）并显著加快下载速度，使 Gentoo 对于低带宽连接的用户更具吸引力。

服务器实现

我建议将补丁放在 Gentoo 镜像上，并存储在一个名为“patchfiles”的新目录中，该目录可以放在“distfiles”旁边。

在 Portage 树中有一个可用的补丁列表将非常有利，以便它可以在“emerge sync”期间更新。可以创建一个名为“dtu.list”的文件并将其放在 $PORTDIR/profiles 中。

如果可以设置一台机器来生成补丁，则它应该包含一个 distfiles 的本地镜像，它可以监控该镜像以添加软件包。当软件包添加到 distfiles 时，机器可以尝试确定以前的 tarball，以便可以制作补丁并将其放在 patchfiles 目录中。此外，可以手动添加特殊情况补丁。

dtu.list 文件将由一个特殊的脚本维护。每当向 patchfiles 目录添加或删除补丁时，脚本都会在 dtu.list 中进行必要的添加/删除。这将在文件中进行最少的更改，以便可以高效地同步。

客户端实现

该系统对用户来说是可选的，可以通过使 Portage 通过 FETCHCOMMAND 环境变量调用 efetch 来启用[3]。

当请求软件包获取时，efetch/fetchcommand 脚本（Deltup 的一部分）将扫描 dtu.list 文件以查找更新，并尝试下载和应用它们（如果存在），或者如果它们不存在或补丁过程失败，则回退到完整软件包下载。

基本原理

最具争议的功能是向 Portage 树中添加 dtu.list，因此在本节中，我将列出我支持它的原因。

  • 灵活性。如果没有它，必须有一个标准的命名方案，一旦系统到位，我们就将被困在其中。更改系统将需要严重的兼容性中断。使用 dtu.list 文件，我们可以轻松地更改命名方案，而不会出现问题，甚至可以拥有几种不同的命名方案。
  • 功能。如果没有补丁信息，则无法检测不同的升级路径。拆分软件包补丁也将不可能。如果信息可用，我们可以使用它来找到最快的升级路径，例如从 .0 版本跳转，或者如果补丁存在问题，甚至可以禁用某些补丁。
  • 在某些情况下，包括重命名的软件包，将无法知道要从哪些软件包升级。
  • 知道哪些补丁可用将消除尝试下载不存在的补丁的开销。

dtu.list 文件将包含数百 KB 的数据。这引起了一些关于它如何有效地进行 rsync 的担忧。为了解决这些问题，文件格式将为纯文本，并且已谨慎考虑在进行删除/添加时最大程度地减少更改次数。

向后兼容性

由于 Deltup 可以生成正确的软件包 MD5 校验和，因此没有向后兼容性问题。

结论

我建议我们从缩减规模的实现开始，并在需求增加时提供更多功能。所有必要的代码都已编写并在非正式测试中运行。