一、补丁机制的核心逻辑

Bigtop 在构建各类组件（如 Ranger、Hadoop、Kafka 等）时，通常会为上游源码引入一些补丁（*.diff 文件），这些补丁不需要你手动修改 .spec 文件，也不需要在构建脚本里显式调用。

这一切的核心机制就是——在 .spec 文件中使用如下占位符：

• #BIGTOP_PATCH_FILES：补丁声明插入位置，如 Patch0: xxx.diff
• #BIGTOP_PATCH_COMMANDS：补丁执行命令插入位置，如 %patch0 -p1

动态注入 这使得你只需关注补丁本身，Bigtop 会自动完成其余所有集成过程。

二、补丁文件的来源与拷贝过程

我们将补丁文件统一放置在如下路径：

bigtop-packages/src/common/<组件名>/

Gradle 脚本中通过如下逻辑，将这些文件拷贝到构建目录：

copy {
  from fileTree("$BASE_DIR/bigtop-packages/src/common/$NAME") {
    include '**/*'
  }
  into "$PKG_BUILD_DIR/rpm/SOURCES"
}

构建完成后，在 build/<组件名>/rpm/SOURCES 下即可看到 patch 文件：

三、注入 .spec 文件的行为解析

当 Gradle 执行到 packages.gradle 中的 patch 注入逻辑时，会扫描补丁目录并自动生成如下内容：

spec 注入逻辑

• #BIGTOP_PATCH_FILES 会被替换为：

  Patch0: patch0-XXX.diff
  Patch1: patch1-YYY.diff
  

• #BIGTOP_PATCH_COMMANDS 会被替换为：

  %patch0 -p1
  %patch1 -p1
  

实际 .spec 文件构建后如下：

四、patch 实际执行效果

.spec 中的 %patch0 -p1 语法，最终会被构建工具解析成标准 patch 命令，如下所示：

# 实际执行命令
/usr/bin/cat rpm/SOURCES/patch0-RANGER-4201.diff | /usr/bin/patch -p1 --fuzz=0 --verbose

如需提前验证补丁是否能成功应用，可使用 dry-run 模式：

# 不影响文件，仅验证是否能成功命中
/usr/bin/patch -p1 --fuzz=0 --verbose --dry-run < patch0-RANGER-4201.diff

执行结果：

可见，补丁命中了 hbase-agent.xml 的第 54 行，提示 Hunk #1 succeeded at 54.。

推荐验证方式 强烈建议在构建前通过 dry-run 提前测试补丁是否能正确应用，避免 RPM 构建失败。

五、补丁源码内容参考

补丁内容通常符合 git diff 标准格式，包含上下文、变更行号、提交作者等信息：

@@ -54,7 +54,6 @@
 <includes>
-<include>com.sun.jersey:jersey-core:jar:${jersey.version}</include>

在构建目录中查看：

六、流程小结

阶段	动作	实现方式
准备补丁	放入 src/common/ranger/*.diff	手动
复制补丁	Gradle 拷贝至 rpm/SOURCES	自动
注入 spec	替换占位符为 PatchN 和 %patchN -p1	自动
执行补丁	构建时自动执行	rpmbuild
验证补丁	使用 dry-run 模式测试	推荐操作

注意

补丁命名需以 patchN- 开头，且放置路径正确，才能被 Bigtop 构建系统正确识别与注入。