文档中心
maint及conan_index说明
更新时间： 2025/12/23
在Gitcode上查看源码

方案概述 ​

组件只有一个开发分支，所有代码都在主干修复和演进，转维版本的缺陷或特性需要由子系统完成上库和测试。组件按需发布补丁，由组件转维版本集成补丁，发布新的构建版本。

整体动作的基本原则：谁需要谁触发，责任owner负责发布补丁。

关键功能 ​

组件转维patch方案主要是完成 组件无分支条件下修改代码并构建发布版本 ，其核心功能包括：

  1. 支持基于组件转维源码重复发布组件。
  2. 支持在组件转维源码基础上追加补丁patch文件，管理多个patch文件和patch顺序。
  3. 提供工程工具简化操作。

基本思路 ​

conan官方仓库 中存储约1600+开源软件构建脚本，大部分都没有侵入式修改开源软件仓代码，对外体现就是开源软件本身没有适配任何conan构建代码。少部分开源软件无法直接使用conan构建的一般采用 拉取到原生代码后应用patch方案 修改构建脚本，最终完成构建。

openubmc的path方案采用conan的包管理方式完成，组件主干代码采用conanfile构建脚本与组件源码共仓管理模式（构建和发布），转维组件采用conanfile构建脚本和组件源码分仓管理模式。

实现方案 ​

构建工程的bingo工具新增manitain辅助命令，帮助开发者生成维护版本构建脚本，支持从主干cherry-pick特定的commit提交或者人工指定patch文件。

openubmc使用conan-index管理开源软件、平台软件和芯片软件管理中，这种方式可以在免修改组件源码条件下实现组件的编译和发布。转维版本也借鉴该方式，由maintain命令在conan-index仓中生成构建脚本和patch文件，编译方式和发布流程与开源软件发布完全一样。

具体的转维组件生成、构建、发布和引用流程为：

  1. 参与下面的场景完成转维版本conan_index代码生成
  2. 构建出包bingo build -cp <name>/<version>，其它参数详见命令帮助
  3. 完成转维版本功能验证
  4. 完成conan_index代码上库
  5. 完成转维版本发布
  6. 在产品引入新发布的转维组件，可能涉及manifest.yml修改和代码上库

maintain子命令说明 ​

maintain子命令了4个参数用于辅助开发者使用:

shell
root@DESKTOP-M0FU0HP:/home/xuhj/workspace/openubmc300/manifest# bingo maint --help
usage: bingo maintain [-h] -cp CONAN_PACKAGE [-p PATCH_FILE] [-b BRANCH] [-c COMMIT_ID]

BMC组件的维护管理工具

optional arguments:
  -h, --help            show this help message and exit
  -cp CONAN_PACKAGE, --conan_package CONAN_PACKAGE
                        指定需要维护的组件版本，示例：iam/1.2.3
  -p PATCH_FILE, --patch_file PATCH_FILE
                        添加patch文件，可指定多个，顺序追加到代码中
  -b BRANCH, --branch BRANCH
                        用于提取patch的分支，与commit_id配合使用
  -c COMMIT_ID, --commit_id COMMIT_ID
                        需要生成patch的提交节点，长度不低于8个字符，可指定多个，顺序追加到代码中。【不推荐使用】生成的patch文件可能存在冲突、功能验证不充分，建议使用-p参数使用人工生成的补丁。

具体实现的基本逻辑为：

  1. 从组件中心仓查找-cp参数指定组件的源码仓url和tag
  2. 自动生成或开发者指定待生成的组件版本号,生成的版本号格式必须为a.b.c-build.x，其中a.b.c是三段式版本号，一般与-cp指定的基础版本保持一致，x为补丁版本号，使用数字。
  3. (如果有)-c参数指定提交id的，需要切换到用于提取patch的分支并提取差异生成patch文件，此过程使用到的命令为git format-patch -1 {commit_id} --numbered-files -- ':!mds/service.json' ':!CHANGELOG'，其中{commit_id}需要替换成真实的提交id，生成的patch文件将以数字命名并会被复制到组件recipes的patches子目录，':!mds/service.json'用于忽略文件名以mds/service.json文件的提交差异，':!CHANGELOG*'用于忽略文件名以CHANGELOG开头的提交差异。
  4. (如果有)-p参数指定的独立patch文件，工具会从源路径复制到组件recipes的patches子目录。

WARNING

生成patch文件时已忽略了mds/service.json和CHANGELOG*文件变更，如果需要该文件内容，请手工生成patch文件。

使用示例 ​

指定patch文件创建转维版本 ​

bingo maint功能可以人工指定patch，需要人工修改源码后再发布版本，执行的流程为“编辑源码 -> 验证功能 -> git提交 -> 生成补丁 -> 创建转维版本”，操作步骤：

  1. 本地代码切换到-cp指定的基础版本。
  2. 执行git cherry-pick提取需要的代码，本地提交解决冲突并验证功能
  3. 执行git format-patch -1 <commit_id> --numbered-files -- ':!mds/service.json' ':!CHANGELOG*' ':!ChangeLog*'命令生成新的patch文件1。注意，其中':!mds/service.json' ':!CHANGELOG*' ':!ChangeLog*'是需要排除的文件，** 建议认真审视，减少非必要的修改** 。
  4. 自动生成的补丁文件名为1，需要重命名为<E2E单号>.patch。

在manifest或conan_index仓操作步骤：

  1. 执行bingo maint -cp <name>/<version> -p <E2E>.patch命令追加patch文件。

转维版本基础再次发布新的转维版本 ​

如果要在一个patch方案发布的转维组件基础上再次使用cherry-pick生成补丁文件时，cherry-pick的基础源码需要打上补丁文件，一般的操作是：

  1. 从conandata.yml中找到patch方案发布的转维组件的tag标签
  2. 下载源码
  3. 从conandata.yml中找到patch方案发布的转维组件的patch补丁，使用git am命令按顺序打上补丁，部分patch可能会报trailing whitespace错误，错误非常困难

上述操作很复杂且可能无法处理异常，bingo fetch命令适配了此场景，建议的完整操作逻辑是:

  1. 执行bingo fetch --package_info=<name>/<version>@hw.openubmc.release/stable命令拉取组件源码并自动打补丁，其中<name>/<version>@hw.openubmc.release/stable是基础转维组件包。
  2. 执行git cherry-pick提取需要的代码，本地提交解决冲突并验证功能
  3. 执行git format-patch -1 <commit_id> --numbered-files -- ':!mds/service.json' ':!CHANGELOG*' ':!ChangeLog*'命令生成新的patch文件1
  4. 自动生成的补丁文件名为1，需要重命名为<E2E单号>.patch。

在manifest或conan_index仓操作步骤：

  1. 执行bingo maint -cp <name>/<version> -p <E2E>.patch命令追加patch文件。

bingo fetch拉取源码 - 自动打补丁 ​

采用 指定patch文件追加新版本 方案，建议在已打补丁的源代码基础上执行发布流程。

其中 已打补丁的源代码 是指在组件代码仓基础代码打上转维版本的全量补丁之后的源码，考虑到人工打补丁比较麻烦，操作易出错，将相关流程集成到bingo fetch命令，实现了拉取源码自动打补丁功能。 命令需要在manifest仓中执行（后续可能会切换到conan_index仓），命令格式为bingo fetch --package_info <name>/<version>@<user>/<channel>，其中<name>/<version>@<user>/<channel>为需要维护的组件。

完整的命令示例：

shell
xuhj@DESKTOP:~/workspace/openubmc300/manifest$ bingo fetch --package_info skynet/1.7.0.B004@hw.openubmc.release/stable
====== 开始获取组件包信息: skynet/1.7.0.B004@hw.openubmc.release/stable ======
创建 1 个进程拉取代码
开始运行命令:  /usr/local/bin/conan download skynet/1.7.0.B004@hw.openubmc.release/stable -r openubmc_dev -re
Downloading conanmanifest.txt completed [0.42k]
Downloading conanfile.py completed [8.07k]
Downloading conan_export.tgz completed [0.52k]
Decompressing conan_export.tgz completed [0.00k]
Downloading conan_sources.tgz completed [23.22k]
Decompressing conan_sources.tgz completed [0.00k]
更新 skynet 组件代码到 skynet/1.7.0.B004@hw.openubmc.release/stable 开始
更新代码(组件: skynet, 地址: https://szv-open.codehub.huawei.com/OpenSourceCenter/cloudwu/skynet.git, 分支: 1.7.0-htrunk1)
开始运行命令:  git am /home/xuhj/.conan/data/skynet/1.7.0.B004/hw.openubmc.release/stable/export_source/patches/0001-Huawei-Replace-lua5.4-to-luajit.patch
Applying: Replace lua5.4 to luajit Offering: openubmc
skynet 应用源码补丁patches/0001-Huawei-Replace-lua5.4-to-luajit.patch

bingo fetch命令默认会将代码生成在source_code目录，如果需要生成到其它目录，可以使用-p PATH, --path PATH 指定拉取源代码的存放路径参数指定目标目录。

ChangeLog ​

2024/12/10：转维版本号格式只允许a.b.c-build.x样式，其中a.b.c是三段式版本号，一般与-cp指定的基础版本保持一致，x为补丁版本号，使用数字。