我们在 Centos 5.5 上运行一个系统，并使用一个包含我们所有软件的 RPM 安装我们的软件。当我们需要应用热修复或补丁时，当前系统只需粘贴 tar 并解压即可。
我正在尝试开发一个可跟踪、可重复的系统来应用热修复和补丁，但我有点不确定 RPM 在这个过程中扮演什么角色。
据我了解，如果我们提高版本号并重新安装，即使只更改了一个文件，那么 RPM 也会爆炸。这要求我们绝对确定没有人在系统上放置了另一个我们不知道的修补程序，因为它将被替换。
是否可以制作一个仅包含新文件的 RPM 并将其应用到现有 RPM 之上？这将如何影响系统的后续升级？
RPM 的重点是具有可重复的、可验证的安装。您应该生成一个包含更新的新 RPM（通过补丁或新的上游源）。
拆分您的整体包将允许您单独升级部件。
问题是更改 rpm 本地安装的文件并忘记它们。
如果您将此用作修补程序过程，则应在修补程序之后立即构建新 rpm，然后部署该新 rpm。
如果允许人们将一个又一个修补程序放在一台机器上而不将其提交到正常进程，那么你就是在招致灾难。
您可以做一件事来提醒您周围有修补程序的事实是使用
rpm -q --verify (your rpm name)
这将打印自安装 rpm 以来已更改的文件列表。这样你至少知道哪些文件被打了补丁并且应该被考虑在内。
您可以使用deltarpm（但我不推荐它，请参见下文）。拥有旧 rpm 和新 rpm（在构建机器上），您可以使用 deltarpm 工具生成 delta。在安装了软件的盒子上使用 deltarpm 工具，您可以自动将旧 rpm 升级到新 rpm（如果需要，可以将其降级）。
我不喜欢它，因为如果旧 rpm 提供的任何（非配置）文件发生更改，您将无法安装修复程序。此外 deltarpm 它不是生产就绪工具。你被警告了。
作为 deltarpm 的替代方案，我建议将您的软件拆分为几个较小的 RPM，并将新 RPM 的子集作为修补程序提供。这是最常见的方法。