RPM 修补程序/补丁方法
我们在 Centos 5.5 上运行系统，并使用包含我们所有软件的一个 RPM 安装我们的软件。当我们需要应用热修复或修补当前系统时，只需粘贴 tar 并将其解压即可。
我正在尝试开发一个可跟踪、可重复的系统来应用修补程序和补丁，但我有点不确定 RPM 在这个过程中扮演什么角色。
据我了解，如果我们提高版本号并重新安装，即使只更改了一个文件，那么 RPM 也会爆炸整个文件。这要求我们绝对确定没有人在系统上安装了我们不知道的另一个修补程序，因为它将被替换。
是否可以制作仅包含新文件的 RPM 并将其应用到现有 RPM 之上？这对系统的后续升级有何影响？
We run a system on Centos 5.5 and install our software using one RPM containing all of our software. When we need to apply a hot fix or patch the current system is simply to stick on a tar and untar it.
I'm trying to develop a trackable, repeatable system for applying hot fixes and patches but I'm a little unsure as to what role RPM plays in this process.
From what I understand if we up the version number and reinstall even with just one file changed then RPM will blast the whole lot. This requires us being absolutely sure that noone has put another hotfix on the system that we're not aware of as it will be replaced.
Is it possible to make an RPM that contains JUST the new files and apply that on top of an existing RPM? How would that affect subsequent upgrades of the system?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
问题是更改了 rpm 本地安装的文件并忘记了它们。
如果您将此用作修补程序，则应在修补程序之后立即构建新的 rpm，然后部署该新的 rpm。
如果允许人们在机器上安装一个又一个的修补程序而不将其提交到正常流程，那么您就会招致灾难。
为了提醒您有修补程序，您可以做的一件事是使用
这将打印自安装 rpm 以来已更改的文件列表。这样您至少知道哪些文件已被修补并且应该被考虑在内。
The problem is changing files locally installed by the rpm and forgetting about them.
If you use this as a hotfix procedure, right after the hotfix you should build the new rpm and then deploy that new rpm.
If people are allowed to put hotfix after hotfix on top of a machine without ever committing it to the normal process, you're inviting disaster.
One thing you can do to be reminded of the fact that you have hotfixes lying around is to use
This will print a list of files that have been changed since the rpm was installed. That way you at least know which files were patched and should be taken into account.
RPM 的要点是实现可重复、可验证的安装。您应该生成一个新的 RPM，并将更新卷入其中（通过补丁或新的上游源）。
拆分整体包将允许您单独升级部件。
The point of RPM is to have repeatable, verifiable installs. You should generate a new RPM with the update rolled into it (via a patch or new upstream source).
Splitting up your monolithic package would allow you to upgrade parts individually.
您可以使用 deltarpm （但我不推荐它，请参见下文）。
有了旧的 rpm 和新的 rpm（在构建机器上），您可以使用 deltarpm 工具生成增量。
在安装了软件的机器上使用 deltarpm 工具，您可以自动将旧 rpm 升级到新 rpm（如果需要，也可以将其降级回来）。
我不喜欢它，因为如果旧 rpm 提供的任何（非配置）文件发生更改，您将无法安装修复程序。此外，deltarpm 它不是生产就绪的工具。你已被警告过。
作为 deltarpm 的替代方案，我建议将您的软件拆分为几个较小的 RPM，并提供新 RPM 的子集作为修补程序。这是最常见的方法。
You can use deltarpm (but I don't recommend it, see bellow).
Having old rpm and new rpm (on build machine) you can generate delta using deltarpm tool.
Using deltarpm tool on box where software is installed you can then automagically upgrade old rpm to the new rpm (and downgrade it back if needed).
I don't like it because if any (non config) file provided by old rpm will get change, you will not be able to install the fix. Moreover deltarpm it is not production-ready tool. You have been warned.
As an alternative for deltarpm I will advice to split your software to few smaller RPMs and deliver subset of new RPMs as a hotfix. This is most commom approach.