Buildroot包补丁：顺序、全局补丁目录与可刷新差异

作者LIU, ZHUOHUI

把补丁栈视为有顺序的构建输入

每个补丁单独看都合理，组合起来仍可能失败。板级改动可能依赖Buildroot先前的修复，上游新版本可能已包含回移植补丁，两个全局目录也可能修改同一处代码。评审对象应是从选定源码到实际参与编译源码的完整有序变换，而不只是当前报错的一个文件。

本文固定Buildroot 2025.02，讨论软件包补丁顺序与可重新整理的差异文件，不讨论内核维护策略。meter-agent仅作目录示例，没有实际应用补丁或构建产品。执行建议步骤时，应使用可丢弃的源码工作区和单独输出目录，保留原有构建证据。

补丁按来源阶段应用，版本目录选择和后置钩子影响最终顺序。
Buildroot 2025.02概念顺序；特定包钩子可能加入额外行为

编辑前清点全部补丁来源

列出软件包版本、下载补丁变量、Buildroot包目录中的补丁、BR2_GLOBAL_PATCH_DIR的全部目录，以及前后补丁钩子。保存产品配置里全局目录的原始顺序。文件名中的0001只约束所属补丁集合内的顺序，不代表它早于其他来源的全部补丁。

普通包流程可对照2025.02补丁策略：先执行前置钩子，下载补丁早于包目录补丁，全局目录按配置顺序随后处理，最后执行后置钩子。个别包可通过钩子加入额外行为，因此还应检查实际配方，不能让这个概要覆盖包自身的规则。

明确版本目录的选择关系

对每个全局目录，Buildroot优先寻找“包名/版本”子目录；存在时使用它，而不是自动把父包目录再当作一层公共补丁合并。没有版本子目录时，才可能回退到包目录。具体选择规则见2025.02定制说明。

board/acme/common-patches/meter-agent/
  0001-fix-cross-compile-probe.patch
board/acme/product-patches/meter-agent/2.4.0/
  0001-add-board-calibration-path.patch

示例表达两个分别配置的根目录，不表示同一父目录和版本子目录会合并。注明哪一层放共用政策，哪一层放产品改动。升级包版本后重新核对实际命中路径，因为旧版本目录可能不再匹配，转而启用另一套回退补丁。

让顺序和目的都清晰可读

使用补零数字加描述性文件名，使所选目录内的字母序具有清晰含义。2025.02仍说明旧series文件的处理，但补丁策略不鼓励新增series文件。新补丁集不宜同时维护两种互相竞争的顺序来源。

一个补丁围绕一个完整目的，头部写清问题、产品为何需要、上游链接或明确状态，以及从原修复所做的适配。重新整理补丁时保留作者和已有签署信息，不替他人编造Signed-off-by。未来维护者应能根据头部说明判断保留、修改或删除，而不是重新猜测当初的动机。

在完整前置栈上重新整理差异

补丁无法应用时，应在准确的源码加全部前置补丁之上重建预期改动。如果产品先应用多个依赖补丁，就不能只对干净上游生成替代差异；也要避免把工作目录中的无关编辑夹带进去。审查最终源码的同时，也要审查新补丁文本。

首先确认新上游是否已经包含修复。“似乎已应用”的提示意味着需要调查，不意味着可以强制反向应用或压制错误。比较上游改动与实际行为，确认效果保留后再删除本地旧补丁。单纯文本相同仍可能漏掉后续修复，或者忽略产品原本增加的适配部分。

从新解包状态重放并保存日志

已经打过旧补丁的构建目录，不能证明新补丁栈正确。为候选配置建立独立输出目录，执行相应补丁和构建阶段，保留原输出。记录源码身份、实际选择的补丁路径、应用顺序，以及工具报告的偏移或模糊匹配信息。

即便补丁带偏移成功，也应在上下文变化时审查修改位置，因为相似代码可能让补丁落到非预期函数。查看改动函数，并测试补丁意图影响的行为。日志有歧义时，以2025.02通用包实现核对真实补丁阶段和钩子，而不是凭操作经验推断。

识别普通流程以外的情况

本地源码与覆盖源码的开发路径可能不同于归档解包流程。2025.02通用包说明明确指出local获取方式不应用普通补丁集合，并提供后rsync钩子用于这类开发路径。开发者已经手工改好的本地目录可以编译，不等于发布配方中的补丁能从头重放。

Linux包还有已记录的顺序例外：BR2_LINUX_KERNEL_PATCH通过后置补丁钩子在全局补丁之后处理。评审对象若是Linux，也必须把这个来源加入清单。普通包政策与特定包行为应分别记录，并查证所选源码标签，不能直接借用更新手册中的顺序断言。

验收与补丁台账

验收要求新解包源码能够命中预期目录，按顺序且仅一次应用所需补丁，并生成预期代码。重要修复还应有针对性行为测试，以及产品配置下的干净构建。这些是建议验收步骤，本文没有执行结果。

为每个补丁维护文件名、目的、来源、上游状态、前置假设和删除条件，并同时记录包版本与Buildroot标签。这样升级评审关注的是每项改动是否仍有必要，而不是无限维持一堆可应用的差异。尚未覆盖的配置和等待硬件的测试，也应在台账中明确标记，避免把“补丁应用成功”误当作功能验收。

类似文章