我们在Centos 5.5上运行一个系统,并使用一个包含所有软件的RPM安装我们的软件。当我们需要应用热修复或补丁时,当前的系统只是简单地粘贴到tar上并解压它。
我正在尝试开发一个可跟踪、可重复的系统,用于应用热修复和补丁,但我有点不确定RPM在这一过程中扮演的角色。
据我所知,如果我们提高了版本号并重新安装,即使只更改了一个文件,那么RPM就会炸毁整个文件。这要求我们绝对确定没有人在系统上放置了另一个我们不知道的热修复程序,因为它将被替换。
是否有可能创建一个只包含新文件的RPM,并将其应用于现有的RPM之上?这将如何影响系统的后续升级?
发布于 2012-08-31 00:39:25
问题是更改rpm本地安装的文件并忘记它们。
如果您将其用作热修复过程,则应该在热修复之后立即构建新的rpm,然后部署新的rpm。
如果人们被允许在一台机器上一个接一个地添加热修复,而从来没有将它提交到正常的过程中,那么你就是在招致灾难。
您可以做的一件事是使用以下命令来提醒您有热修复程序
rpm -q --verify (your rpm name)这将打印自安装rpm以来更改过的文件列表。这样,您至少知道哪些文件打了补丁,并且应该考虑到这些文件。
发布于 2011-04-20 05:42:20
RPM的要点是拥有可重复、可验证的安装。您应该生成一个包含更新的新RPM (通过补丁或新的上游源)。
拆分您的整体式软件包将允许您单独升级部件。
发布于 2011-04-20 01:58:44
你可以使用deltarpm (但我不推荐这样做,见下文)。有了旧的rpm和新的rpm (在构建机器上),您可以使用deltarpm工具生成增量。在安装软件的机器上使用deltarpm工具,您可以自动将旧的rpm升级到新的rpm (如果需要,还可以将其降级)。
我不喜欢它,因为如果旧rpm提供的任何(非配置)文件发生更改,您将无法安装修复程序。此外,deltarpm还不是一个可用于生产的工具。你已经被警告过了。
作为deltarpm的替代方案,我将建议将您的软件拆分为几个较小的RPM,并提供新RPM的子集作为热修复。这是最常见的方法。
https://stackoverflow.com/questions/5486262
复制相似问题