RPM Epoch 标头有任何限制吗?
RPM 支持 Epoch 标头,以便在版本比较不充分的情况下提供版本排序,例如 2.0a3 > 2.0。未指定 Epoch 的包被认为具有 0 或 -1 的 Epoch,具体取决于一些模糊因素。文档建议 Epoch 从 1 开始,并随着每个版本的发布而递增。
Epoch 值有大小限制吗?如果我使用 32 位或更大的值,这会导致任何类型的溢出吗?
RPM supports an Epoch header to provide version ordering in cases where its version comparison isn't sufficient, for example with 2.0a3 > 2.0. A package without Epoch specified is considered to have an Epoch of either 0 or -1, depending on some obscure factors. The documentation suggests that Epoch start at 1 and be incremented with each release.
Does the Epoch value have any size limitations? If I used a 32-bit or larger value, would this cause any kind of overflow?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这真的是一个问题吗?你需要很长时间才能发布 2^32 个版本!无论如何,我在 rpm 源中找到了这个:
所以我想说不要使用 64 位纪元号。 (还有更多的内容 - 它是通过 struct rpmtd_s 读取的,其中有很多奇特的 schmancy void 指针,但是,是的,它是 uint32。)
Is this really an issue? It's gonna take you a long time to have 2^32 releases! Anyway, I found this in the rpm source:
so I'd say don't use a 64-bit epoch number. (There's a little more to it than that - it gets read through the struct rpmtd_s, which has lots of fancy schmancy void pointers, but yeah, it's uint32.)