我被要求从第三方“解压”一个二进制 rpm，替换其中包含的一些 java jar 文件，然后重新打包它，以便它像原始 rpm 一样安装（供内部使用，而不是重新分发）。
我尝试了以下方法：
1) 使用 alien 将 rpm 转换为 tgz，解压缩，修改，重新压缩，然后再次使用 alien 将其从 tgz 转换为 rpm
2) 安装 rpm，修改 jar，然后使用名为 rpmrebuild ( http://rpmrebuild.sourceforge.net/ ) 的工具“重新生成”包。
这两种方法都导致一连串错误消息并且失败了。
我一直在阅读的文档似乎表明尝试修改二进制 rpm 可能不是一个好主意。即来自（https://fedoraproject.org/wiki/How_to_create_an_RPM_package#The_basics_of_building_RPM_packages）的“从预编译代码开始是不行的”
这是徒劳的练习吗？如果没有，我应该尝试其他工具/流程吗？
【问题讨论】：
确实，修补已经构建的 .rpm 文件听起来有问题，最好重新构建它（甚至可能使用稍微不同的名称来清楚地区分它）。 这是我在这个相当奇怪（但在现实生活中当然可能......）案例中会做的事情，假设我们可以在这里忽略任何与许可相关的或法律问题： 从 .rpm 包中解压文件，将它们放入版本控制系统，并在此基础分支的基础上创建一个用于重建的单独分支，在其中添加自定义 .jar 文件，并编写一个自定义 .spec 文件来构建一个 rpm从这些二进制文件打包（具有与原始 rpm 相同的依赖项和 %pre、%post 脚本）。使用此工作流程，您还可以通过将新的解压缩文件检查到基本分支中来跟踪第 3 方“上游”.rpm 包的新版本，并将所需的位移动到另一个分支中，并且易于跟踪已完成的内容与原始包相比更新/修改。还建议在 .rpm 包的描述中澄清该包的情况，并将自己设置为它的维护者。如果其他包依赖于这个包，并且包名称与原始包不同（正如我上面建议的那样），可以使用新 .spec 中的“提供”和“冲突”条目来确保依赖包' 依赖项也由这个自定义包实现，如果原始包已经在系统中（反之亦然），则不会安装这个自定义包。 要创建仅用于安装文件的 .spec 文件，请查看 Build RPM to just install files 或您最喜欢的 rpm 教程。
【讨论】：
-n 参数添加到%setup，如下所示：%setup -q -n namezipunpacksto。
任何阅读本文的人的更新。尝试使用 rpmrebuild 反转 .spec 文件然后重建包是一个繁琐的过程。
最终我们决定在独立于 .rpm 的单独进程中推送不同的 .jar。更简单，更易于维护。
【讨论】：