当前位置：首页 > news >正文

yocto5.2开发任务手册-7 升级配方

news 来源：原创 2025/6/20 21:01:44

此文为机器辅助翻译，仅供个人学习使用，如有翻译不当之处欢迎指正

7 升级配方

随着时间的推移，上游开发者会为图层配方构建的软件发布新版本。建议使配方保持与上游版本发布同步更新。

虽然有多种升级配方的方法，但您可能需要先检查配方的升级状态。可以使用 devtool check-upgrade-status 命令执行此操作。有关更多信息，请参阅《Yocto 项目参考手册》中的 “检查配方的升级状态” 章节。

本节其余部分介绍三种升级配方的方法：可以使用自动升级助手 (AUH) 设置自动版本升级；也可以使用 devtool upgrade 设置半自动版本升级；最后，还可以通过手动编辑配方来升级配方。

7,1 使用自动升级助手 (AUH)

AUH 实用程序与 OpenEmbedded 构建系统配合使用，可根据上游发布的新版本自动为配方生成升级。当您希望创建自动执行升级的服务并（可选）通过电子邮件发送结果时，可使用 AUH。

AUH 允许您一次性更新多个配方。您还可以选择使用镜像执行构建和集成测试，将结果保存到硬盘，并（可选）将结果通过电子邮件发送给配方维护者。最后，AUH 会在图层树中为配方所做的更改创建包含适当提交消息的 Git 提交。

[!NOTE]
在某些情况下，不应使用 AUH 升级配方，而应改用 devtool upgrade 或手动升级配方：

当 AUH 无法完成升级序列时。这种情况通常是由于配方携带的自定义补丁无法自动重新定基于新版本导致的。在这种情况下，devtool upgrade 允许您手动解决冲突。

当出于任何原因需要更全面地控制升级过程时。例如，当您希望为测试进行特殊安排时。

以下步骤介绍如何设置 AUH 实用程序：

1.确保开发主机已设置：需要确保开发主机已配置为使用 Yocto 项目。有关如何设置主机的信息，请参阅 “准备构建主机” 章节。

2.确保 Git 已配置：AUH 实用程序需要配置 Git，因为 AUH 使用 Git 保存升级内容。因此，必须配置 Git 用户和电子邮件。以下命令显示当前配置：

$ git config --list

若未配置用户和电子邮件，可使用以下命令设置

$ git config --global user.name some_name
$ git config --global user.email username@domain.com

3.克隆 AUH 存储库：要使用 AUH，必须将存储库克隆到开发主机上。以下命令使用 Git 在系统上创建存储库的本地副本：

$ git clone git://git.yoctoproject.org/auto-upgrade-helper
Cloning into 'auto-upgrade-helper'... remote: Counting objects: 768, done.
remote: Compressing objects: 100% (300/300), done.
remote: Total 768 (delta 499), reused 703 (delta 434)
Receiving objects: 100% (768/768), 191.47 KiB | 98.00 KiB/s, done.
Resolving deltas: 100% (499/499), done.
Checking connectivity... done.

[!NOTE]
AUH 不属于 OpenEmbedded-Core（OE-Core）或 Poky 存储库。

4.创建专用构建目录：运行oe-init-build-env脚本，创建一个专门用于运行 AUH 实用程序的全新构建目录：

$ cd poky
$ source oe-init-build-env your_AUH_build_directory

不建议重复使用现有构建目录及其配置，因为现有设置可能导致 AUH 失败或行为异常。

5.在本地配置文件中进行设置：在刚为 AUH 创建的构建目录的local.conf文件中需要进行几项设置。请进行以下配置：

若要启用构建历史记录（可选），需要在conf/local.conf文件中添加以下行：

INHERIT =+ "buildhistory"
BUILDHISTORY_COMMIT = "1"

通过此配置且升级成功后，构建历史 “差异” 文件将出现在构建目录的 upgrade-helper/work/recipe/buildhistory-diff.txt 中。

若要启用通过 testimage 类进行测试（可选），需要在 conf/local.conf 文件中进行以下设置：

IMAGE_CLASSES += "testimage"

如果您的发行版未像 Poky 那样默认启用 ptest，则需要在 local.conf 文件中进行以下设置。

DISTRO_FEATURES:append = " ptest"

6.可选地启动 vncserver：如果您在没有 X11 会话的服务器上运行，需要启动 vncserver：

$ vncserver :1
$ export DISPLAY=:1

7.创建并编辑 AUH 配置文件：需要在构建目录中创建upgrade-helper/upgrade-helper.conf配置文件。可在 AUH 源存储库中找到示例配置文件。

通读示例文件并根据需要进行配置。例如，如果如前所述在local.conf中启用了构建历史记录，则必须在upgrade-helper.conf中也启用它。

此外，如果使用 Poky 提供的位于meta-yocto中的默认maintainers.inc文件，且未在upgrade-helper.conf配置中设置 “maintainers_whitelist” 或 “global_maintainer_override”，并在 AUH 命令行中指定 “-e all”，该实用程序会自动向所有默认维护者发送电子邮件。请避免这种情况。

以下示例说明如何使用 AUH：

升级特定配方：要升级某个特定配方，使用以下格式：

$ upgrade-helper.py recipe_name

例如，此命令升级xmodmap配方：

$ upgrade-helper.py xmodmap

将特定配方升级到特定版本：要将特定配方升级到某个特定版本，使用以下格式：

$ upgrade-helper.py recipe_name -t version

例如，此命令将 xmodmap 配方升级到 1.2.3 版本：

$ upgrade-helper.py xmodmap -t 1.2.3

升级所有配方至最新版本并抑制电子邮件通知：要将所有配方升级到最新版本并抑制电子邮件通知，使用以下命令：

$ upgrade-helper.py all

升级所有配方至最新版本并发送电子邮件通知：要将所有配方升级到最新版本，并向每个尝试升级的配方维护者发送电子邮件以及状态邮件，使用以下命令：

$ upgrade-helper.py -e all

运行 AUH 实用程序后，可在 AUH 构建目录中找到结果：

${BUILDDIR}/upgrade-helper/timestamp

AUH 实用程序还会在图层树中为成功的升级尝试创建配方更新提交。

您可以通过使用 cron 作业轻松设置定期运行 AUH 实用程序，示例可参考该实用程序附带的 weeklyjob.sh 文件。

7,2 使用 devtool upgrade

如前所述，将配方升级到较新版本的另一种方法是使用 devtool upgrade。有关 devtool upgrade 的常规信息，请参阅《Yocto 项目应用开发和可扩展软件开发工具包（eSDK）手册》中的 “使用 devtool upgrade 创建支持软件新版本的配方版本” 部分。

要查看 devtool upgrade 的所有可用命令行选项，使用以下帮助命令：

$ devtool upgrade -h

如果您想了解配方当前在上游的版本而不尝试升级本地版本，可使用以下命令：

$ devtool latest-version recipe_name

如前一节描述 AUH 时所述，devtool upgrade 的自动化程度低于 AUH。具体来说，devtool upgrade 仅适用于命令行中指定的单个配方，无法使用镜像执行构建和集成测试，也不会自动为源代码树中的更改生成提交。尽管存在这些 “限制”，devtool upgrade 仍会将配方文件更新为新的上游版本，并根据需要尝试重新定基配方包含的自定义补丁。

[!NOTE]
AUH 在幕后大量使用了 devtool upgrade，因此可以将 AUH 视为 devtool upgrade 的 “包装器” 应用程序。

典型场景涉及使用 Git 克隆构建操作期间使用的上游存储库。由于您过去已构建过该配方，该图层可能已添加到您的配置中。如果由于某种原因该图层尚未添加，您可以使用 “bitbake-layers” 脚本轻松添加。例如，假设您使用 meta-openembedded 存储库中 meta-oe 图层的 nano.bb 配方。在此示例中，假定该图层已克隆到以下路径：

/home/scottrif/meta-openembedded

从构建目录执行以下命令可将该图层添加到构建配置（即 ${BUILDDIR}/conf/bblayers.conf）：


$ bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe
NOTE: Starting bitbake server...
Parsing recipes: 100% |##########################################| Time: 0:00:55
Parsing of 1431 .bb files complete (0 cached, 1431 parsed). 2040 targets, 56 skipped, 0 masked, 0 errors.
Removing 12 recipes from the x86_64 sysroot: 100% |##############| Time: 0:00:00
Removing 1 recipes from the x86_64_i586 sysroot: 100% |##########| Time: 0:00:00
Removing 5 recipes from the i586 sysroot: 100% |#################| Time: 0:00:00
Removing 5 recipes from the qemux86 sysroot: 100% |##############| Time: 0:00:00

在这个示例中，假设上游的 nano.bb 配方版本号为 2.9.3，而本地存储库中的版本为 2.7.4。从构建目录执行以下命令可自动为您升级该配方：

$ devtool upgrade nano -V 2.9.3
NOTE: Starting bitbake server...
NOTE: Creating workspace layer in /home/scottrif/poky/build/workspace
Parsing recipes: 100% |##########################################| Time: 0:00:46
Parsing of 1431 .bb files complete (0 cached, 1431 parsed). 2040 targets, 56 skipped, 0 masked, 0 errors.
NOTE: Extracting current version source...
NOTE: Resolving any missing task queue dependencies...
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 74 tasks of which 72 didn't need to be rerun and all succeeded.
Adding changed files: 100% |#####################################| Time: 0:00:00
NOTE: Upgraded source extracted to /home/scottrif/poky/build/workspace/sources/nano
NOTE: New recipe is /home/scottrif/poky/build/workspace/recipes/nano/nano_2.9.3.bb

[!NOTE]
使用 -V 选项并非必需。省略版本号会使 devtool upgrade 将配方升级到最新版本。

继续此示例，您可以使用 devtool build 来构建新升级的配方。

$ devtool build nano
NOTE: Starting bitbake server...
Loading cache: 100% |################################################################################################| Time: 0:00:01
Loaded 2040 entries from dependency cache.
Parsing recipes: 100% |##############################################################################################| Time: 0:00:00
Parsing of 1432 .bb files complete (1431 cached, 1 parsed). 2041 targets, 56 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies...
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: nano: compiling from external source tree /home/scottrif/poky/build/workspace/sources/nano
NOTE: Tasks Summary: Attempted 520 tasks of which 304 didn't need to be rerun and all succeeded.

在 devtool upgrade 工作流程中，您可以部署和测试重新构建的软件。不过，在此示例中，一旦工作区中的源代码处于干净状态，运行 devtool finish 会清理工作区。这通常意味着使用 Git 来暂存和提交升级过程生成的更改。

一旦代码树干净，您可以在 ${BUILDDIR}/workspace/sources/nano 目录中使用以下命令清理相关内容：

$ devtool finish nano meta-oe
NOTE: Starting bitbake server...
Loading cache: 100% |################################################################################################| Time: 0:00:00
Loaded 2040 entries from dependency cache.
Parsing recipes: 100% |##############################################################################################| Time: 0:00:01
Parsing of 1432 .bb files complete (1431 cached, 1 parsed). 2041 targets, 56 skipped, 0 masked, 0 errors.
NOTE: Adding new patch 0001-nano.bb-Stuff-I-changed-when-upgrading-nano.bb.patch
NOTE: Updating recipe nano_2.9.3.bb
NOTE: Removing file /home/scottrif/meta-openembedded/meta-oe/recipes-support/nano/nano_2.7.4.bb
NOTE: Moving recipe file to /home/scottrif/meta-openembedded/meta-oe/recipes-support/nano
NOTE: Leaving source tree /home/scottrif/poky/build/workspace/sources/nano as-is; if you no longer need it then please delete it manually

使用 devtool finish 命令会清理工作区，并根据您的提交创建一个补丁文件。在此示例中，该工具会将所有补丁文件放回源目录中名为 nano 的子目录中。

7,3 手动升级配方

如果由于某种原因您选择不使用自动升级助手（AUH）或 devtool upgrade 来升级配方，则可以手动编辑配方文件以更新版本。

[!NOTE]
手动更新多个配方的扩展性较差，且涉及许多步骤。建议通过 AUH 或 devtool upgrade 升级配方版本，这两种工具均可自动化部分步骤，并为手动流程提供指导。

要手动升级配方版本，请遵循以下一般步骤：

更改版本：重命名配方，使版本（即配方名称中的 PV 部分）适当更改。如果版本未包含在配方名称中，则直接在配方内部更新 PV 的值。
根据需要更新 SRCREV：如果配方构建的源代码是从 Git 或其他版本控制系统获取的，请更新 SRCREV 以指向与新版本匹配的提交哈希值。
构建软件：尝试使用 BitBake 构建配方。典型的构建失败包括以下情况：
- 针对新版本更新了许可证声明。在这种情况下，您需要审查许可证的任何变更，并根据需要更新LICENSE和LIC_FILES_CHKSUM的值。
- 旧版本配方所包含的自定义补丁可能无法应用于新版本。对于这些情况，您需要审查失败原因。如果升级后的软件版本已修复相关问题，可能不再需要补丁。如果补丁仍必要但应用失败，则需要将其重新定基到新版本。

[!NOTE]
许可证变更通常影响不大。例如，许可证文本的版权年份可能发生了变化。

可选择尝试为多个架构构建：一旦成功为给定架构构建新软件，您可以通过更改MACHINE变量并重新构建软件，测试其他架构的构建情况。如果该配方将公开发布，此可选步骤尤为重要。
检查上游变更日志或发行说明：查看这些内容可了解是否有可能破坏向后兼容性的新功能。如有必要，需采取措施缓解或消除该情况。
可选创建可引导镜像并测试：若需要，可通过将新软件引导至实际硬件进行测试。
在图层存储库中为变更创建提交：在所有构建成功且测试通过后，可为包含已升级配方的图层中的任何变更创建提交。