服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

xyz> xyz-beta(或alpha,rc等)的增量RPM软件包版本“数字”

为了发布一些软件的几个不同版本的RPM软件包,我正在寻找一种方法来指定被认为是“升级”的版本“数字”,并且包括几个预发行版本的区别,例如(按顺序):“2.4.0α1”,“2.4.0α2”,“2.4.0α3”,“2.4.0β1”,“2.4.0β2”,“2.4.0释放候选者”, “2.4.0 final”,“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的预期进行sorting,因为它们的版本显示为随时间增加。 但是,当在几个主要版本上同时发布新版本时(例如,2.3.0在2.4.0之后发布,但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和SLES 11.但是我对那些不涉及重新编译rpm的解决scheme感兴趣。 注3:在类似Debian的系统中,dpkg在版本号中使用一个特殊的组件,即“〜”(代字符)字符。 这会导致dpkg将后缀计为“负数”sorting,所以“2.4.0〜anything”会出现在“2.4.0”之前。 然后,在“〜”之后应用正常顺序,所以“2.4.0〜alpha1”在“2.4.0〜beta1”之前,因为“alpha”按照字母顺序位于“beta”之前。 我不一定希望对RPM包使用相同的scheme(我敢肯定没有这样的等价物存在),所以这只是FYI。