rpm-build limitaitons

我是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无法识别文件的类型，第一个文件是焦油，第二个和其余部分是数据..gzipped拆分部分）。它似乎只解决了一个错误，以提高同样的错误魔术错误，但这次是在最后一部分。
注意：我可以控制以rpm为单位的文件输出的大小。理想情况下，转储完整文件的大小约为4克[以512MB块分割]。但为了测试它确实没有包的大小问题，我稳定地减小了生成的目标文件的大小，并且如果包低于2G，它似乎可以正确工作，并且我可以获得很好的转速。如果我记得正确的大小问题是固定的，因为转速4.4.x.这仍然看起来像cpio问题，这是由rpm使用的归档？rpm-build limitaitons

来源

2013-02-20 Ark

尽管非常规，我通过使用'tar'而不是cpio来解决问题，由在rpmrc中指定'cpiobin'。

来源

2014-01-06 04:42:02 Ark

从老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，4GB对于RPM来说是非常大的，即使对于我们仍然在谈论的内部网络来说，转移和安装它也是相当长的。如果这对您的系统至关重要，那么在开始构建服务器时，是否考虑将其转换为kickstart？

来源

2013-03-02 05:00:58 Forrest

我使用rpm版本4.8。问题是这个包中的'大文件'是一个用于分类的大块数组，它随着数据的进入而变化，因为需要重新训练。至少在现在，将它作为服务提供并不是一种选择。我知道4g是一个非常大的rpm ..关于如何将更新打包到源代码的二进制文件的建议？我不确定这里最有效的方法是什么。 – Ark 2013-03-02 06:16:37

Ark，是否有任何理由认为numpy数组不在需要数据的机器远程访问的服务器上？看起来如果这个阵列继续变大，这个阵列将会出现问题。关于如何打包更新的建议，我真的不知道，只有到目前为止，您将能够压缩该数据，并且似乎您已经探索过此选项。 – Forrest 2013-03-03 16:58:23

理想情况下，我会问，唯一的问题是如何推送更新。我不想让这个受过训练的对象在同一个远程机器上测试，这个机器可以被许多生产机器访问[留下一些其他问题，如瓶颈或意外关机/崩溃，这些问题可以通过复制来解决，我猜也是这样。]无论如何，只有当它通过测试时，它将适合成为'现场'版本。 – Ark 2013-03-05 04:29:57

rpm-build limitaitons

回答

相关问题