项目负责人：aaronwood@google.com 领域：构建、开发者
问题陈述
产品 由 git 的 代码库只有在完成所有软件的编译步骤后，才能“在树内”执行该操作。
产品配置在多个维度（_eng、_eng_arrested、_user、_userdebug、LSDi 等）方面不断激增，因此我们能够为开发者、测试人员和客户所需的每项配置命名。
产品所有者和开发者仍无法轻松表达他们希望在任何给定时间构建/运行的组合。
其中大多数定义都是由于以下维度的组合扩展：
- 即将发货的基础商品
- 组件版本：稳定版, 最新, 开发者
- 商品类型：
eng、eng_arrested、userdebug、user
通过使用指向其他软件包中组件的显式软件包网址，组件拓扑本身会在设备上的 fuchsia-pkg:// 命名空间内晶化，因为每个软件包的完整网址会直接列在其父级的 Cml 中：
- root.cml
- core.cml
如需更改用于实现某些协议的软件包的组件，必须更改某些其他软件包的内容，以引用该不同的软件包网址。
Fuchsia 开发者和发布团队必须在树中管理合作伙伴的所有产品，而树外产品所有者不可能按照自己的时间表发布或更新产品。这给 Fuchsia 组织带来了巨大的负载，增加了产品所有者的阻力。
解决方案声明
为了解决这个问题，我们提议创建一组可以在树外运行的工具，它们将汇编和配置的概念结合到同一进程的几个部分：
汇编过程就是指定：
- 应该使用哪些软件
- 它们为何彼此关联（单个组件的拓扑）
- 如何配置它们
- 何时可以重新配置（以及由谁重新配置）
配置的目的在于提供：
- 每个组件正常运行所需的数据
- 产品的 CFv1 sysmgr 配置
- 产品的整体 CFv2 拓扑
- 内核启动参数
这些是同一流程的两部分：如何为给定产品组装和配置 Fuchsia。
为了实现对 Fuchsia 的受控使用和配置，我们提议引入“子组件”的概念。每个子组件在拓扑片段中定义了一组软件和文件，其中包含配置点和值，并且明确文档说明了在组装过程中可以修改哪些配置。
完成后：
- Fuchsia 平台定义了一些子组件，供产品在执行这种树外组装时选择想要组装的平台行为
- 例如，包含
omaha-client(userdebug/user build) 的软件交付堆栈子组件与使用system-update-checker(eng build) 的软件交付堆栈子组件是有区别的。
- 例如，包含
- 客户产品可以完全在树外组装，而无需直接使用
fuchsia.git - 您可以利用同一组已编译的软件组件组装多个产品变体。
依赖项
将客户产品迁移到使用子组件。这需要咨询 yaar@ 和其他利益相关方，确保我们正确捕获他们的信息。
将 Fuchsia 平台迁移到使用子组件。这需要咨询各个子系统团队，确保我们正确捕获了正确的变体。
若要创建树外映像，某些工具（fvm、blobfs、minfs、zbi、avbtool）需要移植到可在树外使用的格式（用于链接到 Rust 的静态库，或完全移植到 Rust）。
风险和缓解措施
主要风险如下：
新工具不会产生与现有工具相同的输出
- 缓解措施：在 CI/CQ 中并行运行二者，验证新工具是否产生了相同的输出，然后改为使用新工具。
In-Tree 和 Out-Out 工具中的功能可能有所不同
- 缓解措施：将外部工具用作树内工具，因此我们没有两套工具需要维护。
子组件架构设计可以完善。
- 缓解措施：所有架构都将进行版本控制，明确表示希望在此过程中对其进行修改，同时专注于实用解决方案，而不是完美的系统建模。
迁移工作量较大（产品和平台）
- 缓解：可以分阶段完成，从成套组件/标签开始，一直到完全定义的子组件。
- 缓解：实现计划的核心是采用可持续测量的方法，