RPM Epoch 标头有任何限制吗?

发布于 2024-08-08 23:03:50 字数 192 浏览 3 评论 0原文

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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

看轻我的陪伴 2024-08-15 23:03:50

这真的是一个问题吗?你需要很长时间才能发布 2^32 个版本!无论如何,我在 rpm 源中找到了这个:

int rpmVersionCompare(Header first, Header second)
{
    struct rpmtd_s one, two;
    static uint32_t zero = 0;
    uint32_t *epochOne = &zero, *epochTwo = &zero;

所以我想说不要使用 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:

int rpmVersionCompare(Header first, Header second)
{
    struct rpmtd_s one, two;
    static uint32_t zero = 0;
    uint32_t *epochOne = &zero, *epochTwo = &zero;

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.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文