1. 项目概述为什么我们需要亲手制作RPM包在Linux世界里尤其是Red Hat、CentOS、Fedora这些发行版上RPMRed Hat Package Manager包是软件分发和安装的基石。你可能经常用yum install或dnf install来装软件背后拉取的就是一个个RPM包。但当你自己开发了一个C程序比如一个高性能的网络服务工具或者一个桌面小应用怎么把它优雅地分发给用户或部署到生产服务器上直接扔一个编译好的二进制文件过去然后附上一长串依赖库列表和手动配置步骤这显然不专业也极易出错。亲手为你的C程序制作RPM包就是把“手工作坊”升级为“标准化生产线”。它能帮你解决几个核心痛点依赖管理自动化用户无需手动找库、版本控制清晰方便升级、回滚、安装卸载标准化rpm -i安装rpm -e卸载干净利落以及配置文件的规范管理可以标记配置文件避免升级时被覆盖。对于C程序来说这个问题尤其突出因为C运行时库比如glibc、libstdc的版本兼容性是个大坑通过RPM打包可以明确声明依赖避免“在我这跑得好好的到你那就段错误”的尴尬。网上有很多关于pyinstaller打包exe或docker打包镜像的教程但对于Linux原生环境下的C程序制作一个“地道”的RPM安装包仍然是系统管理员和开发者必备的一项硬核技能。这不仅仅是运行一下rpmbuild命令那么简单它涉及对Linux文件系统布局FHS、软件构建流程、包管理规范的理解。接下来我就以一个实际的C项目为例带你走通从源代码到RPM包的全流程分享其中每一步的考量和踩过的坑。2. 环境准备与基础概念扫盲在动手之前我们需要把厨房工作环境和厨具工具链准备好并理解几个关键“菜谱术语”。2.1 打包环境搭建你需要一个基于RPM的Linux发行版来作为打包环境比如CentOS 7/8 Stream、Rocky Linux、AlmaLinux或者Fedora。在Ubuntu/Debian上虽然也能通过rpm包来安装rpmbuild工具但可能会遇到一些库和路径的差异不推荐。这里我以Rocky Linux 9为例。首先安装核心的打包工具链sudo dnf groupinstall Development Tools -y sudo dnf install rpm-build rpmdevtools spectool -yDevelopment Tools这是一个软件包组包含了gcc、g、make、autoconf等编译C/C程序所需的全套工具。这是基础。rpm-build这是RPM打包的核心命令rpmbuild所在的包没有它什么都做不了。rpmdevtools这是一个非常实用的工具集它提供了rpmdev-setuptree等命令能快速初始化标准的RPM构建目录结构强烈建议安装。spectool用于从spec文件中解析并下载源码包方便我们获取项目的源代码。安装完成后初始化你的个人RPM构建目录cd ~ rpmdev-setuptree这个命令会在你的家目录下创建一个rpmbuild目录里面包含以下几个关键子目录~/rpmbuild/ ├── BUILD # 源码解压和编译的地方 ├── BUILDROOT # 模拟安装根目录打包文件从这里收集 ├── RPMS # 编译生成的各种架构的RPM包存放处 ├── SOURCES # 放置源码压缩包(.tar.gz)和补丁文件 ├── SPECS # 放置核心的spec文件打包的“剧本” └── SRPMS # 存放生成的源码RPM包这个目录结构是RPM打包的“标准车间”遵循它能让你的流程清晰也方便与其他开发者协作。2.2 RPM Spec文件打包的“灵魂剧本”整个RPM打包过程都是围绕一个叫做.spec的文件进行的。你可以把它理解为一个构建“剧本”或“菜谱”它用一套特定的语法详细描述了软件信息叫什么名字Name、版本号Version、发布号Release、摘要Summary、详细描述Description等。从哪里获取源码源码包的URL。如何准备和编译解压源码、打补丁、执行./configure、make等步骤。安装哪些文件编译后将哪些文件二进制、库、文档、配置文件安装到系统的什么位置如/usr/bin,/usr/lib64。依赖关系这个软件运行需要哪些其他包Requires以及它会和哪些包冲突Conflicts。安装前后脚本在安装%post或卸载%preun前后需要执行哪些额外的脚本比如创建用户、启动服务。一个最简单的spec文件骨架长这样Name: myapp Version: 1.0 Release: 1%{?dist} Summary: A fantastic C application License: GPLv3 URL: https://github.com/yourname/myapp Source0: %{name}-%{version}.tar.gz BuildRequires: gcc-c Requires: libstdc %description This is a detailed description of my fantastic C application. %prep %autosetup %build make %{?_smp_mflags} %install rm -rf %{buildroot} make install DESTDIR%{buildroot} %files %license LICENSE %doc README.md /usr/local/bin/myapp %changelog * Tue Oct 26 2023 Your Name emailexample.com - 1.0-1 - Initial package后面我们会详细拆解每一个段落的含义和写法。3. 实战将一个C项目打包成RPM光说不练假把式。假设我们有一个简单的C命令行工具叫做hellorpm它的功能就是打印“Hello, RPM!”。项目结构非常简单hellorpm-1.0/ ├── src/ │ └── main.cpp ├── Makefile ├── LICENSE └── README.mdmain.cpp内容#include iostream int main() { std::cout Hello, RPM! std::endl; return 0; }Makefile内容CXX g CXXFLAGS -Wall -O2 TARGET hellorpm SRC src/main.cpp all: $(TARGET) $(TARGET): $(SRC) $(CXX) $(CXXFLAGS) -o $(TARGET) $(SRC) install: mkdir -p $(DESTDIR)/usr/bin cp $(TARGET) $(DESTDIR)/usr/bin/ clean: rm -f $(TARGET) .PHONY: all install clean3.1 第一步准备源码与Spec文件首先我们把项目目录打包成标准的tar.gz格式并放到~/rpmbuild/SOURCES/下cd /path/to/hellorpm-project tar -czvf hellorpm-1.0.tar.gz hellorpm-1.0/ cp hellorpm-1.0.tar.gz ~/rpmbuild/SOURCES/接下来在~/rpmbuild/SPECS/目录下创建 spec 文件hellorpm.spec。这是最核心的一步我们来逐部分编写。头部信息段Name: hellorpm Version: 1.0 Release: 1%{?dist} Summary: A simple demo program to say hello from an RPM package License: MIT URL: https://example.com/hellorpm Source0: %{name}-%{version}.tar.gz BuildRequires: gcc-c make Requires: libstdc%{?dist}这是一个宏会根据你的发行版自动展开成类似.el9、.fc38的后缀用于区分不同发行版的包。这是RPM版本号管理的良好实践。BuildRequires列出了构建这个包时需要的依赖。这里我们需要gcc-c编译器和make工具。Requires列出了运行时需要的依赖。我们的C程序动态链接了libstdc.so所以需要这个库。libstdc这个包名是系统提供的C标准库运行时。描述段%description This is a demonstration package for RPM packaging of a C application. It does nothing but print a friendly greeting to the standard output.%description可以写多行是对软件的详细描述会在rpm -qi命令中显示。准备阶段 (%prep)%prep %autosetup -n %{name}-%{version}%autosetup是一个强大的宏它自动完成了解压Source0指定的源码包、进入解压后的目录、并应用所有补丁如果有的话的工作。-n参数指定了解压后的目录名这里我们让它和源码包名一致。构建阶段 (%build)%build make %{?_smp_mflags}这个阶段就是在源码目录中执行编译。%{?_smp_mflags}是一个条件宏如果系统支持多核编译比如定义了_smp_mflags它会展开成类似-j4的参数加速编译。安装阶段 (%install)%install rm -rf %{buildroot} make install DESTDIR%{buildroot}这是关键一步%{buildroot}就是之前提到的~/rpmbuild/BUILDROOT目录它是一个虚拟的根目录。我们在这里执行make install但通过DESTDIR%{buildroot}参数让make install把文件安装到这个虚拟根目录下而不是真实的系统根目录/。这样我们就把所有需要打包的文件“收集”到了一个地方。文件列表段 (%files)%files %license LICENSE %doc README.md /usr/bin/hellorpm这个段落定义了哪些文件最终会被包含进RPM包。你必须明确列出每一个文件或目录。%license LICENSE这是一个宏它会将源码中的LICENSE文件标记为许可证文件并安装到/usr/share/doc/%{name}-%{version}/下的合适位置。%doc README.md类似地将README.md标记为文档。/usr/bin/hellorpm这是我们程序二进制文件的安装路径。注意这里写的是在最终系统中的绝对路径而不是在%{buildroot}下的路径。RPM打包系统会自动从%{buildroot}/usr/bin/hellorpm找到这个文件。变更日志段 (%changelog)%changelog * Wed Oct 26 2023 Packager Name packagerexample.com 1.0-1 - Initial package for HelloRPM这个段落记录了包的修改历史每次更新版本都需要在这里添加新条目。格式有严格要求。3.2 第二步执行构建与常见问题排查现在我们可以开始构建了。在SPECS目录下执行cd ~/rpmbuild/SPECS rpmbuild -ba hellorpm.spec-ba参数表示“构建所有”即同时生成二进制RPM包和源码RPM包。第一次构建你大概率会遇到错误。别慌这是学习过程的一部分。最常见的错误来自%files段落。RPM在打包前会严格检查%files下列出的每一个文件是否真的存在于%{buildroot}中。如果路径写错或者make install没有把文件安装到预期的%{buildroot}下就会报错“File not found”。排查技巧1检查BUILDROOT目录构建失败后先别急着改spec。去~/rpmbuild/BUILDROOT目录下看看通常里面会有一个以包名和版本命名的临时目录比如hellorpm-1.0-1.el9.x86_64/。进去看看你的文件是否按照预期被安装在了这里例如usr/bin/hellorpm是否存在如果不存在说明%install阶段的make install命令有问题你需要检查你的Makefile的install目标是否正确处理了DESTDIR变量。排查技巧2使用--nobuild和--install选项调试你可以分阶段执行rpmbuild来定位问题# 只执行到 %install 阶段并停在那个阶段方便你检查 buildroot rpmbuild -bi hellorpm.spec执行后去~/rpmbuild/BUILDROOT里检查文件布局。如果文件都在那么问题很可能出在%files段落的路径书写错误。排查技巧3处理目录所有权另一个常见错误是关于文件和目录的归属。在%files段落你可以使用%dir宏来声明一个空目录需要被打包。但更常见的问题是你安装的文件可能属于某个特定的用户/组。在打包时RPM会记录文件的默认归属通常是root:root。如果你需要创建非root用户或指定特殊权限需要在%install阶段用install命令指定或者在%files阶段用%attr()宏覆盖。例如%files %attr(0755, myuser, mygroup) /usr/libexec/my-daemon这指定了文件的权限、所有者和所属组。假设我们修正了所有问题构建成功。你会在~/rpmbuild/RPMS/x86_64/下找到生成的二进制RPM包hellorpm-1.0-1.el9.x86_64.rpm在~/rpmbuild/SRPMS/下找到源码包hellorpm-1.0-1.el9.src.rpm。3.3 第三步安装、测试与验证生成RPM包后我们可以本地安装测试# 安装 sudo rpm -ivh ~/rpmbuild/RPMS/x86_64/hellorpm-1.0-1.el9.x86_64.rpm # 或者使用升级模式如果旧版本存在 sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/hellorpm-1.0-1.el9.x86_64.rpm # 测试程序 hellorpm # 预期输出Hello, RPM! # 查询包信息 rpm -qi hellorpm rpm -ql hellorpm # 列出包安装的所有文件 # 卸载 sudo rpm -e hellorpm通过rpm -ql你可以确认文件是否安装到了正确的位置。卸载后再检查这些位置文件应该被干净地移除除非被标记为配置文件且修改过这涉及到%config宏是另一个话题。4. 进阶技巧与深度优化一个能用的基础包做出来了但一个“专业”的RPM包还需要考虑更多细节。4.1 处理复杂的构建系统CMake/Autotools我们的例子用了简单的Makefile。现实中C项目多用CMake或Autotools。spec文件的写法需要调整。对于CMake项目%build阶段通常是这样%build mkdir -p build cd build cmake .. -DCMAKE_INSTALL_PREFIX/usr -DCMAKE_BUILD_TYPERelWithDebInfo make %{?_smp_mflags}%install阶段%install rm -rf %{buildroot} cd build make install DESTDIR%{buildroot}注意CMake的DESTDIR和Makefile的一样有效它会将文件安装到%{buildroot}/usr/...下。对于Autotools项目通常有configure脚本%build %configure make %{?_smp_mflags}%configure是一个宏它会自动展开为一长串标准的./configure命令包括设置--prefix/usr、--exec-prefix等非常方便。%install阶段则和之前一样使用make install DESTDIR%{buildroot}。4.2 子包Subpackages拆分如果你的软件包含客户端、服务端、开发库等多个部分可以打成一个主源码包生成多个子RPM包。这在spec文件中通过%package指令实现。# 主包定义 Name: mybigapp ... %description The main package for MyBigApp. # 定义客户端子包 %package client Summary: Client utilities for MyBigApp Requires: %{name} %{version}-%{release} %description client This package contains command-line client tools for MyBigApp. # 定义服务端子包 %package server Summary: Server daemon for MyBigApp Requires: %{name} %{version}-%{release} %description server This package contains the server daemon for MyBigApp. %files # 主包的文件列表 /usr/share/mybigapp/common.conf %files client # 客户端子包的文件列表 /usr/bin/mybigapp-cli %files server # 服务端子包的文件列表 /usr/sbin/mybigappd /usr/lib/systemd/system/mybigapp.service这样一次rpmbuild -ba就能生成mybigapp、mybigapp-client、mybigapp-server等多个RPM包。用户可以根据需要选择安装。4.3 系统集成服务与配置文件对于守护进程daemon我们通常需要集成systemd。在%install阶段将写好的myapp.service文件安装到%{buildroot}/usr/lib/systemd/system/。在%files阶段正常列出这个service文件。为了在安装后自动启用服务或在卸载前停止服务我们需要使用脚本片段%post server # 在server子包安装后执行 if [ $1 -eq 1 ]; then # 首次安装 systemctl daemon-reload /dev/null 21 || : systemctl enable mybigapp.service /dev/null 21 || : fi %preun server # 在server子包卸载前执行 if [ $1 -eq 0 ]; then # 完全卸载 systemctl stop mybigapp.service /dev/null 21 || : systemctl disable mybigapp.service /dev/null 21 || : fi重要提示在%post和%preun脚本中所有命令都必须考虑失败的可能性用|| :忽略错误因为脚本是在RPM事务中运行的如果脚本出错导致事务回滚可能会让系统处于一个奇怪的状态。对于配置文件使用%config宏标记这样在升级时如果用户修改了配置文件RPM会尝试合并而不是直接覆盖。如果配置文件是全新的使用%config(noreplace)。%files %config(noreplace) /etc/mybigapp/mybigapp.conf这表示/etc/mybigapp/mybigapp.conf是一个配置文件如果它不存在则安装如果存在说明用户可能修改过则新文件会以.rpmnew后缀保存不会覆盖用户的自定义配置。4.4 调试信息与符号包发布给生产环境的RPM包通常是剥离了调试符号的以减小体积。但为了后续调试我们可以同时生成一个独立的debuginfo包。这通常不需要手动写只要你的编译标志中包含了-g%configure或CMake的Debug/RelWithDebInfo类型通常会加上并且在~/.rpmmacros文件中启用了%debug_package宏rpmbuild就会自动生成一个-debuginfo包。这个包包含了剥离出来的调试符号当程序崩溃时配合gdb和这个包就能看到详细的堆栈信息。5. 持续集成与自动化打包手动打几次包还可以项目迭代频繁后就需要自动化。你可以将rpmbuild命令集成到你的CI/CD流水线中如GitLab CI、Jenkins。通常的步骤是CI Runner拉取代码。执行make dist或类似命令生成tar.gz源码包。将源码包和spec文件可以从代码库中获取放入正确位置。在一个干净的构建环境可以用Docker容器如rockylinux:9中安装rpm-build等依赖。执行rpmbuild -ba。将生成的RPMS/和SRPMS/目录下的包收集为构建产物。使用Docker构建环境可以保证每次构建的依赖一致非常可靠。一个简单的Dockerfile片段如下FROM rockylinux:9 RUN dnf install -y rpm-build rpmdevtools gcc-c make cmake RUN useradd builder USER builder RUN rpmdev-setuptree WORKDIR /home/builder/rpmbuild然后在CI脚本中将源码和spec文件复制到容器内的~/rpmbuild/目录下执行构建命令。6. 避坑指南与经验总结踩过无数坑后我总结了一些血泪教训绝对不要污染真实系统永远记住%install阶段的目标是%{buildroot}不是/。曾经有新手在%install里直接make install没有DESTDIR结果把测试程序装到了真实系统的/usr/local下造成了污染。仔细检查%files列表这是错误高发区。路径必须绝对准确。可以使用rpmbuild -bl specfile命令来只检查%files段它会列出所有将要打包的文件帮你提前发现问题。理解宏和变量%{name},%{version},%{_bindir},%{_libdir}这些都是常用的宏。%{_bindir}通常展开为/usr/bin%{_libdir}展开为/usr/lib6464位系统或/usr/lib。使用宏能让你的spec文件更通用、更规范。处理依赖要精确BuildRequires和Requires尽量写最小集并且版本要求要明确。例如Requires: libcurl 7.29.0。过松的依赖可能导致兼容性问题过紧的依赖可能在不必要的环境下阻止安装。使用rpm -qpR package.rpm可以查询一个已生成包的依赖。%changelog不是摆设每次版本更新务必更新%changelog。这对于下游维护者比如发行版打包者和用户了解变更历史至关重要。格式错误可能导致构建失败。测试、测试、再测试生成包后不要只在自己机器上测试。最好能在一个干净的虚拟机或容器中安装测试验证其安装、运行、升级、卸载的全流程是否正常特别是带有系统服务或复杂依赖的包。最后打包是一门实践性极强的技艺。最好的学习方式就是找一个简单的开源C项目尝试为它写一个spec文件并构建成功。从模仿开始逐步理解每个指令的含义遇到错误就耐心查阅rpm和rpmbuild的man手册或者看看Fedora、EPEL仓库里类似软件的spec文件是怎么写的。当你亲手打造的第一个RPM包被顺利安装并运行时那种成就感绝对比直接make install要来得扎实得多。