项目负责人：aaronwood@google.com 领域：构建、开发者
问题陈述
产品 compiled-time 操作，属于 fuchsia.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 的使用和配置，我们提议引入“子组件”的概念。每个子组件在拓扑图的 fragment 中定义一组软件和文件，并附带配置点和值，并明确说明在组装过程中可以修改哪些配置。
完成后，您将看到以下内容：
- Fuchsia 平台定义了子汇编，产品可以使用这些子汇编在执行此树外汇编时选择要汇编的平台行为
- 例如，包含
omaha-client（userdebug/user build）的软件分发堆栈子组件与使用system-update-checker（eng build）的软件分发堆栈子组件。
- 例如，包含
- 客户产品可以完全在树外组装，而无需直接使用
fuchsia.git - 可以使用同一组已编译软件组件组装多个产品变体。
依赖项
将客户产品迁移为使用子组件。这需要咨询 yaar@ 和其他利益相关方，以确保我们正确捕获了他们的正确方面。
迁移了 Fuchsia 平台以使用子组件。这需要咨询各种子系统团队，以确保我们正确捕获了正确的变体。
如需创建非树内映像，需要将某些工具（fvm、blobfs、minfs、zbi、avbtool）移植到可在非树内使用的格式（静态库以与 Rust 链接，或完全移植到 Rust）。
风险和缓解措施
主要风险包括：
新工具生成的输出与现有工具生成的输出不同
- 缓解措施：在 CI/CQ 中并行运行这两种工具，验证新工具是否会生成相同的输出，然后改用新工具。
树内工具和树外工具的功能可能会有所不同
- 缓解措施：将外部工具用作内部工具，这样我们就不必维护两套工具。
子组件架构设计可以成为追求完美的场所。
- 缓解措施：所有架构都将进行版本控制，以便在流程中进行修改，重点是务实的解决方案，而不是完美地对系统进行建模。
大量的迁移工作（产品和平台）
- 缓解措施：这可以分阶段完成，从一组组组件/标签开始，逐步完成完全定义的子组件。
- 缓解措施：实施计划以谨慎的方法为中心，避免过度扩大范围。