RFC-0271：锚定软件包

问题陈述

目前，Fuchsia 中的系统更新 (“OTA”) 实现需要同时存储两组完整的 blob。这种方法简单明了，但对于磁盘空间不足的设备来说，却存在问题。

摘要

此 RFC 提议实现锚定软件包，该软件包最初在 RFC-212 中进行了描述。这些软件包集满足以下不变性：

• 在系统更新 (OTA) 期间，仅下载永久性、锚定的软件包（根据 RFC-212 的 bootfs、基本软件包）。
• 软件包及其 blob 通过其 Merkle 哈希进行唯一标识。 对于自动锚定和按需锚定的软件包，包含此信息的 meta.far 归档哈希会包含在更新软件包中。
• 自动锚定和按需锚定的软件包会在系统更新应用后以及设备启动到新系统版本后下载。
• 根据 RFC-145，上一点与急切更新尤其不一致，后者根据 RFC-212 映射到一组自动、可升级和永久、可升级的软件包：锚定软件包不会将构成“正确”软件包的身份验证委托给另一方；急切更新允许软件包独立于系统 OTA 进行更新，而锚定软件包则不允许。

不变量对锚定软件包的集合产生了以下影响：

• 如果不执行系统更新，就无法将它们更新到较新版本，因为所有软件包的加密哈希仍随系统更新一起分发。
• 从应用的角度来看，软件包是通过 OTA 分发还是作为锚定软件包分发并不重要。不过，当应用访问尚未解析的软件包提供的功能时，可能会遇到一些延迟。有关这方面的详细信息，请参阅“效果”部分。
• 自动锚定软件包不会按需下载，这与工程 build 中的 TUF 代码库软件包和按需锚定软件包不同。而是会在启动进入更新后的系统后下载。

自动锚定和按需锚定软件包可用于避免在 OTA 期间将系统中的每个软件包在设备的非易失性存储空间中存储两次，从而提高存储效率，尤其是在存储空间受限的设备上。

设计初衷

生产版 Fuchsia 系统上常用的系统更新机制目前通过三分区“ABR”方案执行完整更新。分区 A 和 B 各包含一个完整的系统映像。R 分区包含一个最小的恢复分区，该分区不在本 RFC 的范围内。

在任何时间点，分区 A 或 B 都是有效分区，也就是说，当设备开启时，启动加载程序会将系统启动到有效分区。目前，对于 user buildtype，软件包管理系统已知的所有软件始终可在设备上使用。

执行 OTA 时，系统更新程序会将完整的新系统映像写入非活动分区 A 或 B。此外，它还可确保所有已知 blob 都下载到 A 和 B slot 共享的 fxblob/blobfs 存储空间。成功完成后，它会翻转指示哪个是有效分区的那一位，并重新启动到新的系统映像。这意味着，在任何给定时间，一个完整的系统映像都会占用空间，但根本不会被使用；并且在某个时间窗口内，fxblob/blobfs 必须同时保存当前运行的设备软件版本和新版本的 blob。这样可以更高效地利用设备的资源。 RFC-212 定义并大致规划了 Fuchsia 软件包管理系统扩展的命名规范和概念，以减少系统映像的占用空间。为此，它允许从系统映像中排除软件包，并在系统更新后将软件包下载到 fxblob/blobfs 存储空间。这样一来，旧版和新版软件包就不必同时占用 fxblob/blobfs 上的空间。

支持锚定软件包的另一个动机是希望尽可能减少不必要的网络流量。如果基于 Fuchsia 的系统的大部分用户根本不使用某些软件组件，那么从 OTA 中排除这些组件并仅在需要时下载它们，可能会显著减少要传输的数据量，从而降低服务器和网络所需的容量。

定义

以下术语和定义适用，如 RFC-212 中所定义：Base、Bootfs packages、Cache、Eager update、Garbage collection、Package、Package set、Package version、Parent package、Permanent package、Product、Product build、Product release、Subpackages、System update、Universe、Versioning authority。

利益相关方

辅导员：

jamesr@google.com

审核者：

• etryzelaar@google.com (SWD)
• amituttam@google.com（产品经理）
• awolter@google.com（软件组装）
• markdittmer@google.com（安全）
• gtsai@google.com（基础设施）

共同化：

此 RFC 在软件交付团队内部的一系列设计讨论中进行了讨论。此 RFC 中的文本的早期版本已与软件交付、构建和组装团队中的利益相关者以及潜在客户进行了审核。

要求

• 锚定软件包的交付机制不应需要额外的服务或基础设施，也就是说，将系统更新 (OTA) 交付到目标设备的相同机制也应适用于锚定软件包。
• 软件包属于哪个锚定软件包集的规范是手动完成的。根据此 RFC，不会实现任何尝试自动确定哪个软件包可能属于哪个软件包集的机制。
• 实现范围限定为 RFC-212 中定义的限制，如下面的插图所示。具体而言，以下场景不会通过自动或按需锚定的软件包进行涵盖或支持：
  • 支持版本控制的委托。
  • 支持对产品开箱即用体验 (OOBE) 工作流程至关重要的软件包。
  • 这意味着，如果对 OOBE 至关重要的软件包被标记为自动或按需锚定的软件包，软件包管理堆栈将无法保证在需要时提供成功完成 OOBE 工作流程所需的所有软件包。这是因为在许多情况下，OOBE 工作流包括设置网络。因此，无法保证在 OOBE 完成之前解析自动和按需锚定的软件包。

设计

锚定的软件包集

软件包集是一组软件包，所有这些软件包都使用相同的策略进行交付和更新。生产设备中最常用的软件包集是永久（基本和 bootfs）集，它们具有以下主要特征：始终可用且由产品定义设置：

• 描述软件包的 Merkle 哈希，确保软件包的完整性，
• 以及软件包本身

在重新启动进入更新后的产品版本之前，会作为 OTA 更新流程的一部分下载。因此，再加上 Fuchsia 的默认 ABR 分区方案（其中 A 分区和 B 分区都包含完全可启动的系统），基本集中的软件包可能会在 fxblob/blobfs 中存储两次：如果它们不同，则商店中会存储 A 分区中产品的一个版本，以及 B 分区中产品的一个版本。在运行的系统中，基本集中的软件包列表会反映在基本软件包的 data/static_packages 文件中。在软件包解析过程中，这些软件包由 pkg-cache 的一部分基本解析器解析。换句话说，它们在本地解析，不需要网络连接。

自动和按需 锚定软件包集与启动文件系统集和基本集有一些共同的特征，但在根本上有所不同：

• 与基本软件包一样，描述锚定软件包的 Merkle 哈希会在重新启动到新系统版本之前下载到目标系统分区。
• 与基本软件包和 bootfs 软件包不同，在重新启动到新系统之前，blob 本身不会下载到 fxblob/blobfs。

这样可以针对存储空间大小优化 OTA 更新的下载阶段，因为可以避免在非易失性存储空间中保留软件包的多个版本。下文的“使用自动锚定软件包的启动序列”对此进行了说明。

自动和按需 锚定软件包之间的区别在于导致软件包解析器提取软件包的触发器：

• 当任何有权在运行的 Fuchsia 系统上查询解析器的符合条件的组件请求解析按需锚定的软件包时，系统会立即提取该软件包。
• 在执行 OTA 后重新启动到新的 Fuchsia 系统时，自动锚定的软件包会尽快得到解析。

锚定软件包的垃圾回收

此 RFC 建议，在未来对垃圾收集算法进行潜在修订之前，以下规则适用于锚定软件包的收集：

• 自动锚定软件包下载到 fxblob/blobfs 后，在下次重启到较新的系统之前，将受到垃圾收集的保护。
• 只有当系统版本（以及 Merkle 哈希）发生变化，并且它们不再是当时正在运行的系统版本的一部分时，自动锚定的软件包才会受到垃圾回收的影响。
• 按需锚定的软件包不会受到垃圾收集的额外保护，并且会遵循有关开放软件包跟踪的 RFC-217 中指定的规则。

按需锚定的软件包的解析

软件包解析器已具备下载软件包并按需在运行的系统上提供这些软件包的功能。因此，利用此功能实现按需锚定软件包非常简单：一旦解析出系统上没有的软件包，软件包解析器就会下载 blob，这些 blob 将经过验证并通过 fxblob/blobfs 提供。

始终可用软件包集与自动/按需 锚定软件包之间的主要区别在于，对于后两者，解析器需要互联网连接。

从正在运行的系统的角度来看，按需锚定的软件包不必明确标记为按需锚定。当请求某个软件包时，解析器只会注意到其 blob 在软件包缓存中不可用，并启动下载过程。

不过，开发者可以决定是否将某个软件包作为按需锚定的软件包包含在产品中，并且需要在产品定义中将其标记为按需锚定：

• Fuchsia 产品定义将接受 on_demand_anchored 软件包的列表。
• ffx assembly product 工具将能够将该列表输出到映像组装配置。

在产品组装期间：

• 相应软件包（blob 和清单）包含在主商品 bundle 中。
• 这些 blob 不包含在用于刷写设备的 fxblob/blobfs 中。
• 按需锚定集中的软件包列表的构建方式与基础软件包类似。该列表将成为 AssemblyManifest 的一部分，并包含在更新软件包中。运行中的 Fuchsia 系统会在基础软件包的 data/anchored_packages 文件中找到此集合的软件包列表。

解决了自动锚定软件包的问题

与按需锚定的软件包一样，开发者需要决定是否将某个软件包作为自动锚定的软件包包含在产品中，并且需要在产品定义中将其标记为自动锚定：

• Fuchsia 产品定义将接受 automatic_anchored 软件包的列表。
• ffx assembly product 工具将能够将该列表输出到映像组装配置。

在产品组装期间：

• 相应软件包（blob 和清单）包含在主商品 bundle 中。
• 这些 blob 不包含在用于刷写设备的 fxblob/blobfs 中。
• 自动锚定集中的软件包列表的构建方式与基本软件包类似。该列表将成为 AssemblyManifest 的一部分，并包含在更新软件包中。运行中的 Fuchsia 系统会在系统更新软件包的 data/anchored_packages 文件中找到此集合的软件包列表。

在重启进入新的或升级后的 Fuchsia 系统后，此集中的软件包会得到解析。如前所述，这与 data/static_packages 中的软件包有显著不同，后者始终存在且为 pkg-cache 所知。

具有自动锚定软件包的启动序列

如果系统具有一组自动更新的软件包，则其启动顺序如下：

• 在首次启动新设备或在 OTA 后重新启动设备后，当确认网络连接正常时：
  • 系统将执行 fxblob/blobfs 垃圾回收，以逐出之前系统版本中存在的悬空 blob。
  • 如果网络连接不可用，垃圾收集会延迟到网络可用时进行。
• 启动序列会像往常一样完成，并且基本集的所有软件包都已可用。
• 在启动序列完成时，软件包解析器将检查是否存在自动锚定集中的每个 blob，并开始下载 fxblob/blobfs 中不存在的所有 blob。
• 如果发生下载错误，解析器将继续检查自动锚定集中的缺失 blob，并在系统累积正常运行时间时重试下载缺失的 blob。

软件包可能无法使用

与仅提供永久软件包的系统不同，一旦按需或自动锚定软件包开始发挥作用，就无法再保证所有软件包始终可用。

默认情况下，启动过程不会因下载失败或下载缓慢而受阻，除非产品明确要求此行为并正确实现它。主要有两个原因：

• 设备甚至可能尚未配置网络连接，必须先完成开箱体验 (OOBE) 工作流，然后才能下载按需或自动锚定软件包。
• 可能不利于用户体验。例如，在下载一组自动 锚定软件包期间，设备可能会遇到互联网连接丢失的问题，而用户想要使用设备的一项简单功能，该功能可通过基本软件包集轻松获得。

请注意，由于软件包至少可能会间歇性地不可用，因此依赖于这些软件包的组件必须能够妥善处理这种情况。具体而言，对可能需要通过网络获取的组件的调用无法保证在特定时间内完成，因为大多数使用情形下的网络延迟和速度都是未知的。如需了解详情，请参阅“报告软件包的可用性”部分。

报告套餐的提供情况

与设备上始终提供所有已知软件包的情况相比，OTA 后下载和节省 OTA 存储空间的好处是以可预测性为代价的。这可能会产生相关要求，例如：

• 组件可能需要在调用特定函数之前了解依赖项是否已准备就绪或是否仍在下载。
• 尤其是用户互动型应用，可能需要实现一种机制来监控调用某些功能提供程序时意外出现的长时间等待，并向用户显示消息来管理他们的预期。
• 跟踪或调试工具可能需要检查有关软件包可用性的详细数据或指标，例如软件包是否存在、是否正在下载、下载速度、延迟时间、重试次数等。

在撰写此 RFC 时，我们尚不完全了解具体详细的要求以及由此产生的对 Fuchsia 平台的更改。因此，本文档不讨论此类监控和可用性报告的详细设计。此问题可能会在未来的 RFC 或实现中得到解决。

根据目前的规划，debug_agent 或 zxdb 等工具可能会率先使用某种形式的可用性报告和监控。这样可以更好地了解要求、差距以及未来需要解决的必要变更。复杂的用例（例如与交互式界面互动、向最终用户报告进度以及类似情况）不在这一初始用例集的范围内。

实现

实现将分为多个阶段，以便参与团队之间进行同步，并在为基于 Fuchsia 的产品启用该功能之前验证该功能。

第一阶段将包含在软件包解析器和软件包缓存中实现纯功能，这需要：

• SWD
  • 支持在启动时从基本软件包的 data/anchored_packages 获取自动锚定软件包的列表，并使自动锚定软件包的 blob 可用。
• 构建、汇编
  • 支持在产品 build 期间处理所需的自动和按需锚定软件包列表，并向映像提供 data/anchored_packages。
  • 更新了大小检查工具，以支持锚定软件包并正确反映 build 和映像大小。
• 安全性
  • 对自动和按需锚定软件包的解决方案的面向互联网的代码路径进行技术审核。

第二阶段将包括准备工作，以便为基于 Fuchsia 的产品启用新功能。这需要：

• SWD
  • 准备现有产品配置的变体，将一些软件包从基本集移至自动或按需锚定集。
• 服务器端打包基础架构
  • 用于存储软件包并与 blob 存储区集成。

第三阶段将把自动或按需锚定的软件包集成到基于 Fuchsia 的产品中，并提供第一个应用。此决定超出了 RFC 的范围。不过，从概念上讲，这需要：

• 所选应用 / 维护团队和测试团队
  • 查看并调整应用，使其能够处理依赖项暂时不可用的情况。
  • 创建和调整测试及测试方案，以模拟和运行可能出现的一系列错误状态（下载速度缓慢、DNS 问题、连接中断、开箱即用体验等）。
• 版本管理
  • 确保已进行端到端产品测试，以保证 OTA 和 OOBE 工作流不依赖于按需软件包。
  • 引导包含锚定软件包的版本完成所有阶段，并最终向基于 Fuchsia 的产品的用户全面推出。

data/anchored_packages 文件

实现的核心要素是系统如何识别自动和按需锚定的软件包。如前所述，它们将列在 data/anchored_packages 中，类似于 data/static_packages 文件。不过，与 static_packages 文件的简单键值对格式不同，此文件将传达更多信息，以便自动和按需锚定的软件包在开始时：

• 是自动还是按需。
• 由其网址标识的软件包。
• 软件包哈希值。

因此，data/anchored_packages 文件将是一个 JSON 文件，其中包含以下信息（概念上）：

{
  "on_demand": {
    "fuchsia-pkg://fuchsia.com/package1": {
      "hash": "d5eb4bb8a394176f20a266bac7cd8a077579f57119c5e1ed0981cd5ea563c183"
    },
    "fuchsia-pkg://fuchsia.com/package2": {
      "hash": "d33da6cb5fc8787ae1386e85ff08a32c6e846668d5eb4bb8a394176f20a2681c"
    }
  },
  "automatic": {
    "fuchsia-pkg://fuchsia.com/package3": {
      "hash": "d189658d88636999abe2c4375409ace94fd0408d338e96692b8b8bad07c484d4"
    },
    "fuchsia-pkg://fuchsia.com/package4": {
      "hash": "e6c22775bac3301f18d012493ffc6c7fe442b59cd5eb4bb8a394176f20a266ba"
    }
  }
}

性能

此 RFC 对性能的影响可分为以下几个方面：

1. 基于 Fuchsia 的产品在运行时针对 fxblob/blobfs 上提供的软件包的性能。我们预计此方面的运行时性能不会有明显变化，因为对于锚定集中的已解析软件包，它们在软件包缓存提供方式或运行方式方面与基本软件包没有区别。

2. 在运行时，基于 Fuchsia 的产品对于软件包管理已知但尚未下载的软件包的性能。从 CPU 和内存消耗方面来看，软件包的解析（下载、验证）对基于 Fuchsia 的产品的总体性能影响预计较小。不过，在产品用户想要执行依赖于仍在下载的软件包的功能时，这种影响可能会很明显。在这种情况下，用户体验会在一定程度上受到影响，具体取决于下载速度。影响程度主要取决于用户互联网连接的速度和延迟时间，因此不在本 RFC 的讨论范围之内。请注意，设备端应用可以根据仍在下载的软件包向用户说明情况，例如通过消息告知用户所需的下载仍在进行中。从用户体验的角度来看，这比设备显示无响应或处于未知状态要好。

3. 对于使用自动锚定软件包的产品，OTA 流程的总时长会有所变化。我们预计，平均而言，“系统更新软件包下载已开始”与“新 build 正在运行”之间的时间会缩短，“系统更新软件包下载已开始”与“所有软件包均已解析”之间的平均时间会延长。如上一个要点中所述，关于解决 fxblob/blobfs 上尚不可用的软件包，建议依赖于非永久性软件包的软件做好管理用户期望的准备。对于某些类型的设备，这种时长变化可能不太成问题，例如在夜间不使用时定期更新的设备。

4. 与将更新作为单个 OTA 分发的产品相比，当向采用自动或按需锚定软件包的产品提供服务时，软件包服务基础架构很可能会遇到不同的负载模式。这取决于多种因素，例如，在自动锚定软件包的情况下，设备在收到更新软件包后何时重新启动；在按需锚定软件包的情况下，用户何时首次请求某些功能。但同时，地理位置以及用户是否使用某些功能等其他因素也会导致软件包服务基础架构的负载与仅向具有静态软件包的产品提供服务时不同。相关方面将在“未来工作”部分中讨论。

5. 鉴于上述几点，建议您针对以下情况设置指标：(i) 更新软件包的下载和安装时长；(ii) 首次重新启动到新 build 后，自动锚定软件包的解析时长。这样可以更好地了解在成功应用系统更新后，用户体验因网络连接不稳定或下载速度缓慢而受到影响的频率。

基准

利用锚定软件包的产品可能会在用户可见的 activity 方面有所不同。因此，对于此类产品，我们建议定期收集其他基准，以确保用户体验不会退化，并在基准表明出现退化时采取应对措施：

• 在各种已定义的网络条件（上行链路 / 下行链路速度、延迟时间、丢包等）下，特定产品的一组自动和按需锚定软件包的解决时间。
• 在各种已定义的网络条件下，锚定软件包的解析尝试失败的频率。
• 用户基于 Fuchsia 的产品请求依赖于尚未解析的软件包的功能的频率。

这些指标旨在提供数据，以便合理决定是否可以将某个软件包移出基本集，或者是否应将锚定软件包移回基本集。

工效学设计

工程工作流

工程工作流与目前使用工程 build 可完成的工作基本相同，即从提供 TUF 代码库的代码库服务器动态提供软件包。一般来说，组件不应处理其依赖项的可用方式的较低级别详细信息，而软件包解析过程会抽象出这些详细信息。

我们预计，如果发现差距，我们会扩展围绕 ffx 的现有工具，以支持锚定软件包的测试和开发工作流程。

向后兼容性

此工作将向后兼容软件交付堆栈的现有用途。软件包网址命名空间结构或解析概念不会发生变化。

此工作不会弃用现有功能。因此，除非使用锚定软件包，否则更改完全透明。

安全注意事项

此提案存在安全注意事项。它们与 RFC-145 略有重叠，但从根本上讲，此提案更为良性。

• 与 RFC-145 类似，我们在系统运行时解析软件包，也就是说，软件包解析器需要连接到互联网的权限，至少在所有软件包都已解析且 blob 存储在 fxblob/blobfs 中之前需要此权限。
• 与 RFC-145 不同，此提案不会委托有关可运行软件包集的权限。在启动进入新的 OTA 时，整个软件包宇宙的所有哈希都是已知的。因此，产品定义和有效软件包的构成与仅使用基本软件包的产品相同。

隐私注意事项

我们认为，该提案不包含任何会影响隐私的新功能。不过，应考虑以下几点：

我们建议在“基准比较”部分中更早地介绍新指标。这些指标旨在导致用户体验退化。如果此类基准数据是从生产设备收集的，则在引入之前应先通过隐私保护审核。

测试

软件交付堆栈的新扩展功能将通过对现有测试套件的扩展进行覆盖，并将涵盖单元测试、集成测试和端到端测试，从而覆盖所有新的代码路径。

测试还将涵盖以下场景：锚定软件包的解析依赖于成功的先前垃圾回收，以及面临磁盘接近满的场景。

为了评估利用锚定软件包的基于 Fuchsia 的产品的用户体验，应验证关键用户工作流，尤其是在网络条件不理想的情况下。

文档

接受此 RFC 后，我们将：

• 更新了“软件包”的术语表条目。
• 更新“概念”中有关软件包的部分。
• 更新了“IDK 中的软件包”页面。
• 更新了“入门指南”中有关产品软件包的页面。
• 添加了有关使用锚定软件包时如何配置更新的信息。

缺点、替代方案和未知因素

替代方案：为基于 Fuchsia 的产品使用其他分区方案

此替代方案与之前侧重于软件交付机制的方案在语义范围上并不相同，并且在很大程度上与此 RFC 正交。但它侧重于自动和按需锚定软件包的一个重要原因：节省基于 Fuchsia 的产品在非易失性存储设备上的空间。

人们经常会假设这些产品是基于 ABR 分区方案构建的：

• A 和 B 作为可容纳整个系统映像的分区
• R 作为紧急情况下的恢复分区，当 A 和 B 都无法使用时

虽然它是一种经过验证的概念，已应用于各种类型的众多设备，但肯定不是唯一的选择。至少还有两种可能性可以节省近一半的空间：

• AR 方案：只有一个系统分区 (A)。OTA 是通过启动到恢复映像 (R) 来执行的，然后系统分区 (A) 会被覆盖。
• AB 方案：A 和 B 都包含可用于重新刷写另一个系统分区的恢复软件，而不是为恢复功能单独设置一个分区。

虽然这些替代分区方案旨在为受限设备提供更多可用磁盘空间，但它们与专注于软件包本身有很大不同，从节省空间的角度来看，它们可以被视为正交。不过，锚定软件包也可以满足其他目标，例如减少网络流量，因此更改分区方案是一个应独立于此提案进行评估的选项。

未来的工作

移除了 data/static_packages 文件

我们可能会选择弃用并移除 data/static_packages 文件，并将该文件中列出的软件包包含在用途更广泛、可扩展性更强的 data/anchored_packages 文件中。

Notification API

此 RFC 未涵盖此方面的内容，但我们将来可能会选择实现某种形式的通知 API，组件可以查询软件包解析状态、下载速度或下载完成估计时间等信息。

在系统更新软件包中包含软件包内容 blob

根据未来的要求，我们可能会选择不仅在更新软件包中包含软件包的 meta.far 文件，还包含软件包内容 blob。例如，这可能有助于估计自动和按需锚定软件包的下载时间。

针对特定工作流程进行优化

借助软件包集，可以针对特定工作流程进行优化。不过，这些优化可能会产生额外的费用，或者实现起来可能很复杂，尤其是在考虑所有极端情况时。因此，这些考虑因素不在本 RFC 的讨论范围内。不过，为了提供相关背景信息，我们列出了一些潜在的优化措施：

• 积极利用按需软件包可以处理比已定义产品的组合集软件包更小的 fxblob/blobfs 存储空间。在这种情况下，按需软件包可能会经常被垃圾回收，并且需要重新下载需要使用的软件包。虽然可以实现，但需要仔细设计此类产品上可能的工作流程，以保证始终有足够的存储空间来存放任何给定时间正在使用的所有软件包。
• 这样一来，就可以将自动或（大部分）按需锚定的软件包包含在用于刷写的初始 fxblob/blobfs 映像中，从而无需在初始开箱体验后下载这些软件包。虽然可以这样做，但会在初始映像和后续 OTA 之间引入细微差异，可能会给组装和测试带来复杂情况。

其他开发者工具

通过纳入自动或按需锚定的软件包，我们可以为开发者提供更多工具。构建哪些工具不在本 RFC 的讨论范围内，但一些潜在的工具包括：

• 报告并美观地打印软件包依赖关系图，突出显示对并非始终可用的软件包的直接依赖关系和传递依赖关系。
• 通过 ffx repository serve 向开发目标提供软件包时，模拟非理想的网络条件，例如网络速度慢或连接时断时续。

重新审视软件包服务基础架构

根据可能从采用自动和按需锚定软件包的产品中收集的网络指标，运行软件包服务基础架构的团队可以获得有助于优化服务基础架构的洞见，从而缩短用户的下载时间或延迟时间。预期方面包括（例如）：

• 软件包工件的存储分区在云区域中的分布。
• 通过负载均衡来最大限度地缩短客户端的访问延迟时间，并使用 IP 地理定位等方法来确定最近的软件包服务器。
• 在推出较大更新时，动态扩缩软件包服务器的实例数量。
• 在次要版本和主要版本发布之前，预测预期负载模式。

在先技术和参考资料

• fuchsia.dev 中的软件包
• Eager package updates RFC
• 子文件包 RFC
• 前期启动软件包 RFC
• 软件包设置 RFC