在完成组件编译后，如何将产物标准化迁移到打包目录，成为 RPM/DEB 集成链路的关键一环。只有严格按照 buildroot 的要求归集文件，才能保证后续打包工具（如 rpm, dpkg）能够正确识别、打包出标准的 Linux 发行件。

为什么要处理 buildroot？

1. 隔离编译与打包：编译目录通常包含临时文件、测试文件等杂项，直接用于打包极易引入冗余或脏数据。
2. 标准化路径结构：不同组件、不同平台对文件路径有严格要求。例如 bin、lib、conf、man、doc 必须落在固定目录，否则会导致服务启动或包安装异常。
3. 后续运维友好：标准的目录结构方便自动化部署、升级、运维等后续工作。

归集流程概览

以下为 Redis 在 bigtop-packages/src/common/redis 下典型的归集操作步骤：

步骤	说明
1. 创建脚本	编写 install_redis.sh，定义迁移与整理逻辑
2. 目录初始化	按标准规范创建 bin、lib、etc、doc、man、var 等目录
3. 产物拷贝	按需将编译产物、配置文件、文档等拷贝进 buildroot
4. 链接优化	创建软链接、剔除冗余、保证路径兼容

install_redis.sh 脚本内容

目录结构效果示意

迁移完成后，整个 buildroot 下 Redis 的组织结构类似如下：

/BUILDROOT/
 ├── usr/
 │   ├── lib/redis/
 │   │     ├── src/       # redis 可执行文件
 │   │     ├── redis-*    # redis 主程序与组件
 │   │     ├── *.so
 │   │     ├── redis.conf -> /etc/redis/redis.conf
 │   │     └── sentinel.conf -> /etc/redis/sentinel.conf
 │   ├── share/doc/redis/ # 文档
 │   ├── share/man/man1/  # man 帮助
 │   └── etc/redis/
 │         ├── conf.empty/
 │         ├── redis.conf
 │         └── sentinel.conf
 └── var/log/redis/

后续补充说明

本节暂不详细解读 install_redis.sh 脚本的具体实现逻辑。 原因很简单： 当前阶段直接讲解脚本内容会让人“一头雾水”，容易陷入细节，而忽略整体流程。后续章节将专门展开讲解，结合实际打包过程、RPM 结构，以及与 SPEC 脚本的集成场景来逐步拆解。 请关注后续补充章节：

• 👉 Step7-Log-安装细节
• 👉 Step8-Log-制品细节