xyz> xyz-beta（或alpha，rc等）的增量RPM软件包版本“数字”
为了发布某些软件的几个不同版本的RPM软件包，我正在寻找一种方法来指定被认为是“升级”的版本“数字”，并包括几个预发行版本的区别，例如（为了）：“ 2.4.0 alpha 1”，“ 2.4.0 alpha 2”，“ 2.4.0 alpha 3”，“ 2.4.0 beta 1”，“ 2.4.0 beta 2”，“ 2.4.0版本候选”， “ 2.4.0最终版本”，“ 2.4.1”，“ 2.4.2”等 我遇到的主要问题是RPM认为“ 2.4.0”早于“ 2.4.0.alpha1”，因此我不能仅在最终版本号的末尾添加后缀。 我可以尝试使用“ 2.4.0.alpha1”，“ 2.4.0.beta1”，“ 2.4.0.final”，除了“发行候选”晚于“ 2.4.0.final”外，它们都可以工作”。 我考虑过的替代方法是使用RPM版本号的“ epoch：”部分（在主版本号之前考虑epoch：前缀，这样“ 1：2.4.0”实际上早于“ 2：1.0.0”） 。通过将时间戳记放在epoch：字段中，所有版本都会按照RPM的要求进行排序，因为它们的版本似乎会随着时间增加。但是，如果同时在多个主要版本上进行了新发行（例如，在2.4.0之后发行2.3.2，但其RPM版本为“ 20121003：2.3.2”和“ 20120928：2.4”），则此操作将失败。 0”和2.3.2上的系统无法“升级”到2.4.0，因为rpm将其视为较旧的版本）。在这种情况下，yum / zypper / etc拒绝升级到2.4.0，因此是我的问题。 我可以使用什么版本号来实现此目的，并确保RPM始终认为版本号是有序的。或者，如果不是版本号，则使用RPM包装中的其他机制？ 注意1：我想保留spec文件的“ Release：”字段，以保留其原始用途（对于同一版本的打包软件，会发行多个版本的软件包，包括打包更改）。 注2：这应该适用于主要发行版的当前生产版本，例如RHEL / CentOS 6和SLES11。但是，我对那些不需要重新编译rpm的解决方案也很感兴趣！ 注3：在类似Debian的系统上，dpkg在版本号中使用特殊组件，即“〜”（代字号）字符。这导致dpkg将后缀计为“负”顺序，因此“ 2.4.0〜anything”将出现在“ …