RPM 构建限制答案

【问题标题】：Rpm-build limitaitonsRPM 构建限制
【发布时间】：2013-02-06 04:18:52
【问题描述】：

我是 rpm 打包的初学者，据我了解，由于 cpio 限制，rpm-build 文件大小>4GB 存在问题。因此，我将包中的大文件拆分为 gnu 拆分为 512MB 的文件 [这是作为 rpmbuild 的一部分完成的，因为大文件是在构建时生成的]。我仍然看到错误： “错误：在文件 /io1/dm/build/BUILDROOT/pkg/installdir/lib/clfsplitab 上创建存档失败：cpio: Bad magic”其中 clfsplitab 是大文件的 512MB 拆分。关于任何建议如何追踪确切的问题？还是有更好的方法来处理/生成大型有效载荷包？
更新： 如图所示，错误出现在 clfsplitab 上，即拆分的第二个文件（因为 gnu split 通常拆分后缀为 aa、ab、ac 等的文件。看起来 cpio 无法识别文件的类型，第一个文件是 tar，第二个和其余的是 data..gzipped 分割部分）。似乎只解决了一个错误来引发同样的坏魔法错误，但这次是在最后一部分。
注意：我可以控制 rpm 中文件的输出大小。理想情况下，转储的完整文件大小约为 4g [分成 512mb 块]。但是为了测试包大小确实没有问题，我稳定地减小了生成的目标文件的大小，如果包低于 2G，它似乎可以正常工作，并且我得到了一个很好的 rpm。如果我没记错的话，尺寸问题自 rpm 4.4.x 起已修复。这看起来仍然像 cpio 问题，rpm 用于归档吗？

【问题讨论】：

标签： split rpm rpmbuild

【解决方案1】：

来自老RPM 4.6 documentation：

Large package support

Packages can now theoretically be up to 64bit sizes, and individual files within packages are limited to 4GB each due to cpio format limitation whereas they were previously limited to ~2GB. Large packages (over ~2GB in size) are incompatible and unreadable with previous versions of RPM due to requiring 64bit integer type support in headers, "normal" sized packages are fully compatible with older versions however.
Limitations on accepted header size can cause limit the practical package size when the number of files in a package is extremely high.

所以是的，这很可能仍然是 CPIO 问题。您使用的是哪个版本的 RPM？我认为你应该重新评估你的 RPM，对于一个 RPM 来说 4GB 是非常大的，即使对于一个内部网络，我们仍在谈论很长一段时间来传输和安装它。如果这对您的系统很重要，您是否考虑过在最初构建服务器时将其纳入 kickstart？

【讨论】：

我使用的是 rpm 版本 4.8。问题是包中的这个“大文件”是一个用于分类的大型 numpy 数组，它随着数据的进入而变化，因为需要重新训练。将其作为服务提供不是一种选择，至少目前是这样。而且我知道 4g 对于 rpm 来说非常大。关于如何使用源代码将更新打包到二进制文件有什么建议吗？我不确定这里最有效的方法是什么。
Ark，numpy 数组是否有任何理由不在需要数据的机器远程访问的服务器上？如果这个数组继续变大，看起来这个数组将会有问题。关于如何打包更新的建议我真的不知道，到目前为止，您将能够压缩该数据，而且您似乎已经探索过这个选项。
理想情况下我会，唯一的问题是如何推送更新。例如我不想在同一台远程机器上测试这个训练有素的对象，许多生产机器都可以访问它[撇开瓶颈或意外关机/崩溃等其他问题，我猜这些问题可以通过复制来解决]。无论如何，只有当它通过测试时，它将适合成为“实时”版本。

【解决方案2】：

虽然非常规，但我通过使用 'tar' 而不是 cpio 解决了这个问题，在 rpmrc 中指定“cpiobin”。

【讨论】：