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