bingo基于build配置生成组件版本依赖关系，user字段无法定制

CICD SIG
,
1

问题背景

1.原本期望是能够用上conan中的user字段，用于区分社区conan包和自有conan包，因此自有的conan包名会是mdb_interface/1.110.11@wuzhou/stable
2.在切入2606版本时，遇到如下报错

Resolved version ranges
    hica/[>=1.70.14 <1.71.0]@openubmc/stable: hica/1.70.14@openubmc/stable
    observability/[>=1.110.2 <1.130.0]@openubmc/stable: observability/1.120.4@openubmc/stable
ERROR: Version conflict: Conflict between mdb_interface/[>=1.80.1]@openubmc/stable and mdb_interface/1.110.11@wuzhou/stable in the graph.
Conflict originates from observability/1.120.4@openubmc/stable

问题分析

1.根据报错判断是observability组件依赖mdb_interface/[>=1.80.1]@openubmc/stable但是在manifest当中又指定了mdb_interface/1.110.11@wuzhou/stable，导致不知道用哪个版本的mdb，从而产生的报错
2.分析observability组件中的service.json和conanbase.py文件

service.json

build中指定了mdb_interface版本范围

        "build": [
            {
                "conan": "libmc4lua/[>=0.0.1]"
            },
            {
                "conan": "mdb_interface/[>=1.80.1]"
            },
            {
                "conan": "opentelemetry/1.13.0.022"
            }
        ]

conanbase.py

自动生成的构建文件中指定了user和channel

    def requirements(self):
        # 编译依赖
        self.requires("libmc4lua/[>=0.0.1]@openubmc/stable")
        self.requires("mdb_interface/[>=1.80.1]@openubmc/stable")
        self.requires("opentelemetry/1.13.0.022@openubmc/stable")
        skynet = self.conf.get("user.tools:skynet")

3.借助ai分析bingo源码
下放关键代码部分，其默认生成的conanbase，如果service.json指定了build的组件版本，那么是会默认生成user为openubmc

    @staticmethod
    def get_dependencies_v2(service_data, key):
        dependencies = []
        user_channel = f"@{misc.conan_user()}/stable"
        deps = ComponentHelper.get_config_value(service_data, key, [])
        for dep in deps:
            conan = dep.get(misc.CONAN)
            if conan is None:
                log.info("获取 conan 依赖失败, 跳过未知组件")
                continue
            if conan.find("@") < 0:
                conan += user_channel
            if not misc.conan_package_match(conan, True):
                raise BmcGoException(f"未正确定义依赖组件的名称: {conan}")
            dependencies.append(conan)

        return dependencies

4.分析了一下之前为什么不会遇到的原因，原先我们刚好把build有依赖的组件都进行了定制化，或组件本身未指定依赖mdb版本，但是目前较新的组件，基本都在build中增加了mdb版本依赖

一些修改方案
1.修改组件依赖，build下不放mdb --修改组件可能过多，而且破坏原本指明的依赖关系，且组件都需要重新构建
2.采用options形式，沿用openubmc —修改量可能过多，每个组件都需要单独修改定制
3.直接取消user区分，沿用openubmc —无法根据包名进行区分自有和社区版本

疑问

按照当前情况分析，存在组件依赖user字段(openubmc)的情况，那么user字段不方便作为定制版本区分，请教一下社区各位大佬，基于当前情况，有没有更加合理的方案

2

答案内容由AI生成，仅供参考：

五、结论

您的分析是正确的：bingo 默认生成的依赖中，user 字段会补全为 @openubmc/stable，这导致直接修改 user 来区分自有/社区包会与上游组件产生冲突。最稳妥的做法是，保持底层组件的 @openubmc/stable 身份不变，转而通过版本号、远程仓库配置或显式依赖声明来管理自定义软件包。如果一定要在 user 字段上进行定制，需要同步修改并重新构建所有相关依赖组件，否则难以避免版本冲突。

点击此处查看详细分析解答

根据您提供的信息和现有上下文，可以得出以下分析与建议。

一、问题确认

您遇到的现象与社区中已有的讨论一致：bingo 在生成组件构建脚本（conanbase.py）时，如果 service.json 中声明的依赖没有显式写明 @user/channel，会自动补全为 @openubmc/stable（参考话题 3021 的回复以及您的源码分析）。例如：

self.requires("mdb_interface/[>=1.80.1]@openubmc/stable")

这种自动补全在组件构建时就会嵌入到该组件的 Conan 构建脚本中，发布后即固化。因此，当您在 manifest 中指定 mdb_interface/1.110.11@wuzhou/stable 时，由于上游组件（如 observability）已经固化了 @openubmc/stable 的依赖，就会产生版本冲突。

二、社区已有的明确结论

在话题 3021 中，针对类似问题（mdb_interface 版本冲突）的回复明确指出：

“在 service.json 中，如果申明的组件没有带 @user/channel，则会自动补全为 @openubmc/stable，这种依赖关系在组件构建时就嵌入到了组件的 conan 构建脚本中，发布后就固化。
mdb_interface 是一个很底层且大部分组件都依赖的组件……
因此：mdb_interface 这类很底层且被大量依赖的组件，不要修改这类组件的 @user/channel，除非你能将所有依赖同步修改到位。”

这说明，对于被广泛依赖的底层组件，通过修改 user 字段来区分自有/社区包是不可行的，因为依赖图已经因自动补全而“锁死”在 @openubmc/stable 上。

三、可参考的定制方式

1. 在构建上传时指定 user，并在依赖中显式声明

话题 1153 的回复提供了一个可行的方法：

bingo build --upload -r <remote> --user=openUBMC.common --stage rc

然后在 manifest.yml 的依赖中显式写明完整的 @user/channel：

- conan: byo_general/0.0.1@openUBMC.common/rc

但该方法要求所有依赖方都显式引用该 user/channel，且“和 bingo 没关系，属于 conan 的概念，需要团队自行规划”。

2. 推送带源码的自定义 user 包到远端

话题 1329 中描述了一种变通方式：当某个版本的包无法源码构建时，可以主动推送一个带源码的、user 设置为目标值的版本到远端，从而让 bingo 解析到该包。
不过这种方法仅在依赖关系没有强制绑定 @openubmc/stable 时才有效；对于像 observability 这类已经固化了 @openubmc/stable 依赖的组件，推送 @wuzhou/stable 的包并不能被解析为目标依赖。

3. 如果坚持使用自定义 user

必须同时满足：

  • 所有依赖该底层组件的组件，在 service.json 中显式写明自定义的 @user/channel；
  • 这些依赖组件需要重新构建并重新发布，以便让固化后的依赖关系指向新的 user。

这实际上就是“将所有依赖同步修改到位”，工作量会非常大，且容易遗漏。

四、当前情况下更合理的方案

综合上下文信息，建议：

  1. 不要修改 mdb_interface 这类底层组件的 user/channel，继续使用 @openubmc/stable。
  2. 改用版本号或远程仓库来区分自有包与社区包。例如：
    • 将自有包发布到独立远程仓库（如 openubmc_dev）；
    • 通过版本号差异（如 1.110.11 vs <1.110.11>）来选择包；
    • 在构建前确认依赖可用的 remote 优先级，避免拉取到错误的包。
  3. 如果您确实需要区分“自有”和“社区”版本，建议在 manifest 层或远程仓库层做控制，而不是在 Conan 的 user 字段上做文章——因为该字段已经被底层依赖的自动补全机制占用。

五、结论

您的分析是正确的：bingo 默认生成的依赖中，user 字段会补全为 @openubmc/stable，这导致直接修改 user 来区分自有/社区包会与上游组件产生冲突。最稳妥的做法是，保持底层组件的 @openubmc/stable 身份不变，转而通过版本号、远程仓库配置或显式依赖声明来管理自定义软件包。如果一定要在 user 字段上进行定制，需要同步修改并重新构建所有相关依赖组件，否则难以避免版本冲突。

3

请参考AI答复处理，底层组件不建议变更user/channel，建议只在自有的顶层组件中控制user/channel（不会被其它组件依赖或全量依赖关系可以适配修改时）