openSUSE:软件包版本控制指南

跳转到：导航，搜索
openSUSE 软件包版本控制指南应有助于决定在版本行中放入什么。

一般来说，版本行中.spec文件的版本应遵循上游压缩包的版本。

如果无法做到，请检查以下解决方案中是否有一个能解决您的问题。

不寻常字符

RPM 使用破折号来分隔软件包名称、软件包版本和发行版级别的重新发行（“发布”）计数器。（例如，`rpm -qa` 输出coreutils-9.0-1.x86_64。）破折号本身不能用于版本或发布子字符串中，其他一些字符如星号也不行。大多数软件使用点作为分隔符，一切正常。然而，有些项目不遵循所有约定。任何不是字母数字字符或点的字符都应该直接替换为点。波浪号字符不受此处理，因为它用于测试版排序（见下文）。

SCM 快照

从 SCM 存储库创建压缩包时，请使用最近的适用发布版本，附加“+”分隔符和标识 SCM 类型和 SCM 特定的单调递增标识符的短标签。此方案的常见应用示例

Git 可以将提交表示为与标签的偏移量，以生成相对较短的标识符。例如，如果 `git describe` 输出v3.14.1-5-g9265358，则 rpm 版本可以设置为 3.14.1+git5，或者，如果需要更多消歧，则设置为 3.14.1+git5.g9265358。如果 git 存储库维护者只使用简单标签而不是带注释的标签，您可能需要使用 `git describe --tags`。如果维护者不提供 git 标签，请报告此缺点。同时，可以通过使用历史记录根作为基础（`git rev-list 9265358 | wc -l`) 获取替代的单调递增标识符，这在项目处于早期阶段尚未发布时很有用（Version: 0~git123).

Subversion 具有可直接使用的修订号。但是，基本版本需要以其他方式确定。版本：3.14.1+svn592。

对于 CVS，时间戳似乎是最短的无歧义（至少对开发人员而言）快照标识符，因为所有文件都有自己的修订树。版本：3.14.1+cvs20130621。

预发布软件包

使用与最终发布版本号相同的预发布版本需要额外注意。不同的开发人员对如何命名他们的预发布版本有不同的想法；“1.8b”可能表示在 1.8 之前出现的 1.8 beta 版，也可能表示在 1.8 之后实际发布的版本。因此，软件包实用程序（正确地）不会对“alpha”、“beta”、“a”、“b”或任何其他名称进行特殊处理，并且通常按最长字符串排序，以便“1.8”在“1.8b”之前。发行版软件包维护者需要根据我们实用程序提供的排序顺序调整 .spec 文件中的版本字段。有多种方法可供选择，但请只选择一种。按降序偏好（= 选择适用的第一个），它们是

  • 一些上游为其预发布版本分配了可排序的数字（其他正常发布版本不会获得）。例如，sssd-1.8.0beta2.tar.gz被定义为“1.7.92”。使用Version: 1.7.92.
  • 使用“波浪号版本”。spec 的 Version: 字段可能包含波浪号作为特殊标记，它在任何其他内容（包括字符串结尾）之前排序，即“1.8~” < “1.8”。此功能从 rpm-4.10 开始可用（并已向后移植到 openSUSE 12.2 的 rpm 4.9.1）。使用Version: 1.8.0~beta2。如果确实需要，波浪号可以多次使用。
    • 如果上游压缩包不包含波浪号字符，您可能会发现以下用于从版本中删除波浪号的 lua 宏很有用
Version:        1.8.0~beta2
%define pkg_version %{lua: print((string.gsub(rpm.expand("%{version}"), "~", "")))}
Source:         https://example.com/%{name}-%{pkg_version}.tar.gz
etc.
  • 对于最终发布版本，选择一个在上游最终版本之后但在任何未来发布版本之前排序的版本字符串。（选择确实有限。）Version: 1.8.0.beta2用于预发布，Version: 1.8.0.0用于最终发布。这依赖于 RPM 按 A-Z 在 0-9 之前排序的属性。您已经注意到，rpm 不会直接按 ASCII 值排序，因此，如果您计划也使用 OBS 为非 RPM 系统构建，此变体可能不一定有效。
  • 对于预发布版本，选择一个在最终版本之前但在系列中任何潜在的未来发布版本之后排序的版本，并用它作为实际版本的前缀。Version: 1.7.99_1.8.0beta2用于预发布，Version: 1.8.0用于最终发布。
  • 增加Epoch字段。请注意，openSUSE 不鼓励并且不使用 epoch，其中一个原因是 zypper 实际上可以使用 `zypper dup` 和 `zypper in` 处理降级（与 yum 不同，大概）。实际上，Epoch 被认为是有害的，引用了《Maximum RPM》一书
解决方案二：直接说不！ 如果您可以在更改软件的版本号方案或在 RPM 中使用 epoch 数字之间做出选择，请考虑更改版本号方案。很有可能，如果 RPM 无法弄清楚，大多数使用您的软件的人也无法弄清楚。


也不要试图滥用 rpm 的 Release: 标签来表示版本信息。它是传递此信息的错误字段，并且 Open Build Service 默认情况下无论如何都会通过签入和构建计数器覆盖 Release:。

发布后软件包

总的来说，发布后版本通常不会造成问题，因为上游通常会将其版本化，使其遵循最终发布版本。

如果上游使用允许字符集中的分隔符，则直接将其用于版本字符串。否则，将其替换为允许的字符。

  • openssl-0.9.8pVersion: 0.9.8p
  • suse-11-GA1Version: 11.GA1# GA=通用可用性

同样，对于仅对人类有意义的字母字符串（如这里的 GA），可能需要加上一个数字作为前缀，以帮助按照上游的意图进行排序，如果 A-Z 的自然顺序不足的话。假设 FUBAR 在 GA 之后，那么

  • suse-11-GA1Version: 11+0.GA1
  • suse-11-FUBAR1Version: 11+1.FUBAR1

将是一个可行的解决方案。您会注意到维基页面编辑者在这里选择的是“+”而不是“.”作为分隔符，以避免出现有些歧义的版本（11.0.GA1 可以解释为 11.0+GA1 或 11+0.GA1）。

对于预发布到发布后版本，只需使用上面描述的波浪号机制（“openssl-0.9.6q~betaX”）。

摘自“https://en.opensuse.net.cn/index.php?title=openSUSE:Package_versioning_guidelines&oldid=177644”