Buildroot虚拟包：选择实现提供者并消除依赖歧义
先定义接口，再选择实现
虚拟包适合表达“应用需要某个接口，产品可以选择不同实现”。它本身不能证明两个库可以随意替换。开始写配置前，应列出公共头文件、链接名称、必须提供的函数、最低功能集合、目标架构以及运行时资源。例如软件图形实现与依赖特定GPU的实现可能暴露相似接口，但部署条件完全不同。本文固定使用Buildroot 2025.02源码规则，传输接口示例是虚构设计，不是已有上游包，也没有声称已经编译或上板验证。
本题关心的是实现选择能否在配置与构建图中保持一致。先把接口承诺写清楚，后续才知道某个错误来自选择机制，还是来自实现能力不足。不要把虚拟包当作自动兼容层。
区分能力标志与提供者名称
虚拟包通常声明隐藏的能力布尔符号，以及记录提供者包名的字符串。真实实现启用能力标志，并在自身被选择时为字符串给出默认值。虚拟包的make文件调用virtual-package基础设施，不再额外下载一份实现。这些职责可对照2025.02虚拟包说明核实。
config BR2_PACKAGE_HAS_TRANSPORT_API
bool
config BR2_PACKAGE_PROVIDES_TRANSPORT_API
string
depends on BR2_PACKAGE_HAS_TRANSPORT_API
$(eval $(virtual-package))字符串必须对应Buildroot中的实际包名，不能填产品型号、共享库文件名或任意显示标签。能力标志为真但名称为空，意味着配置边界已经不完整。统一符号前缀，并在审查时同时检查声明、默认值和消费者引用。
让产品明确选择一个实现
假设实现名为transport-posix，它的配置选择HAS_TRANSPORT_API，条件默认值指定transport-posix，make文件再声明TRANSPORT_POSIX_PROVIDES = transport-api。另一个实现也需要完整对应关系，并保留自己的真实依赖。如果两个实现会安装冲突文件，产品配置应阻止同时启用，不能依赖多个默认字符串的排列顺序解决冲突。
特别要避免消费者偷偷select某个提供者。用户可能已经显式启用了另一种实现，结果两者一起进入配置。官方说明要求：确实依赖特定提供者时，消费者应使用depends on该提供者；仅依赖公共功能时，应依赖共享能力标志。这样的限制更容易在菜单和评审中被看见。
把构建依赖接到虚拟节点
菜单是否可见与构建先后顺序是两件事。示例消费者可以在Config.in中依赖BR2_PACKAGE_HAS_TRANSPORT_API，在make文件中加入CLIENT_DEPENDENCIES += transport-api，再由虚拟节点指向所选实现。遇到空实现报错或宿主包依赖异常时，应检查2025.02实现代码中的实际规则。
编译头文件来自提供者的staging安装，运行库来自其target安装。增量构建能链接成功，不代表依赖正确，旧提供者遗留的文件可能正好掩盖问题。保存完整编译链接命令，再使用新的输出目录验证。不要手工向staging复制文件来消除错误，否则下一次干净构建仍会失败。
如实表达实现之间的能力差异
同一接口名称经常覆盖不同功能子集。一种传输实现可能只支持轮询，另一种支持异步完成。如果应用必须依赖异步操作，就应增加明确能力条件，或者限制到特定提供者，而不是悄悄关闭应用的重要功能来换取构建通过。
建立提供者能力表，分别记录头文件、符号、支持模式、运行资源和许可证责任。每格标为已验证、不支持或待验证。符号存在但运行时总返回“不支持”，不能算满足契约；绑定某设备系列的厂商实现，也不会因为接入虚拟包机制就自然具备跨平台能力。对这些差异应给出可执行的消费者测试。
有意验证无效配置
至少准备四种状态：没有提供者、只选实现A、只选实现B，以及试图同时选择冲突实现。第一种应使消费者不可选，或者产生预期的配置失败；两种单实现状态应解析到正确包；冲突状态应按产品规则被阻止或明确拒绝。每次保存最终配置与提供者字符串，不只截取菜单画面。
随后加入一个依赖专用扩展的消费者。即使公共能力标志为真，错误的实现也不应使它可用。这个反例能够发现“镜像看似有效，应用却假定了未声明功能”的缺陷。公共接口测试与提供者专用测试应分开记录，使失败能够定位到具体承诺。
按边界解释失败现象
空实现错误优先检查包名字符串；缺少头文件检查所选实现、staging安装与构建顺序；重复文件或库检查冲突选择及旧输出污染；构建成功但运行操作不支持，则回到能力表。这些只是排查假设，必须用配置与日志确认，不能直接当作根因结论。
切换提供者时保留旧输出，另建比较目录，核对文件系统内容和链接依赖变化。两个实现如果使用相同库文件名，更容易掩盖实际链接对象。还应确认新实现没有继续依赖旧实现附带的配置、固件或启动资源，避免只检查二进制文件就宣布替换完成。
验收与交付边界
验收应同时满足：配置明确选中预期实现，make依赖能够到达它，开发文件确实由它提供，各个受支持实现通过同一消费者契约。再保留一个不支持扩展的负向测试，证明错误配置不会被意外放行。交付材料包含精确Buildroot版本、产品配置、能力表和相关日志。
这套检查证明的是选择与集成关系，并不证明硬件加速效果、吞吐性能或长期ABI稳定。实际性能仍需独立产品试验。最有价值的交付结论是哪些实现可以替代、哪些功能不能替代，以及维护者如何识别超出承诺范围的新配置。
