930版本整包构建报组件依赖冲突

CICD SIG
1

代码版本：930
sdk和bingo/bmcgo均已更新

【问题现象】
我们在修改了mdb_interface组件后推包修改了组件用户名，在manifest仓库中修改成我们自己的组件版本和用户名后进行整包构建报如下错误：

ERROR: Version conflict: Conflict between mdb_interface/[>=1.80.1]@openubmc/stable and mdb_interface/1.90.119@xxx.xx/stable in the graph.
Conflict originates from observability/1.90.24@openubmc/stable

Run 'conan graph info ... --format=html > graph.html' and open 'graph.html' to inspect the conflict graphically.
e[31mERROR: 执行命令 conan lock create . -pr=profile.ini -pr:b profile.dt.ini -r artifactory -s:a build_type=Debug  -o firmware_mgmt/*:community_enable=False -o bmc_time/*:manufacture=True -o libmgmt_protocol/*:storelib_enable=True -o */*:enable_luajit=True -o vpd/*:board_name=S920X20 -o fructrl/*:manufacture=True -o rackmount/*:oem=huawei -o chassis/*:manufacture=True -o webui/*:energy_enabled=True -o webui/*:ldap_enabled=True -o */*:module_symvers=1ee923e971f1cf759b9b1cf3df4fbdf4182b1eb2d5f267ef64494e6ea0bf9b86 --lockfile-out=/home/workspace/source/JD_920BS_DEV/manifest/temp/build_openUBMC_debug_dev/openubmc.lock 错误, 日志: /home/workspace/source/JD_920BS_DEV/manifest/temp/log/task.loge[0m

【问题初步分析】
看着报错信息，是因为manifest里面配置的mdb_interface版本和observability依赖的mdb_interface版本有冲突，主要是因为mdb_interface版本要求mdb_interface的用户名必须是@openubmc，但是我看observability里面依赖没有写@openubmc

image
image876×644 9.01 KB

【疑问】
为什么observability的组件依赖会默认是@openubmc，导致我们出自己的组件无法构建通过

2

有几点原因：

  1. 在service.json中，如果申明的组件没有带@user/channel则会自动补全为@openubmc/stable，这种依赖关系在组件构建时就嵌入到了组件的conan构建脚本中，发布后就固化。
  2. mdb_interface是一个很底层且大部分组件都依赖的组件，你看到版本号冲突信息跟observability单个组件没有关系，就算你将observability对mdb_interface的依赖改成@xxx.xx/stable也会有其它组件报冲突。

因此：mdb_interface这类很底层且被大量依赖的组件，不要修改这类组件的@user/channel，除非你能将所有依赖同步修改到位。

3

谢谢，还有一个问题请教一下，如果我改了这个组件之后，有没有什么方法可以和社区conan仓库里面的mdb_interface做区分呢，如果我们不改@openubmc/stable，会不会导致我们想拉我们自己出的conan包最后去下载了社区的conan包这种情况，当前我们的虚拟仓库是社区仓在前，本地仓在后

image
image1104×833 33.7 KB

4

使用代理仓模式时，conan首先会查找你自己的仓，找不到再去代理仓查找（但使用版本号范围查找依赖场景未验证过，建议实地验证一次），理论上你可以发布一个相同的组件并放在你的个人仓中。

但在某些场景下可能会导致你管理困难，建议按以下原则处理：

  1. 社区开源组件建议由社区中心仓管理。
  2. 如果确需发布某个组件私有包，建议在依赖管理时（组件的service.json或产品manifest.yml）指定明确版本号，确保不会引用非预期的组件。