第 3 章 打包软件

名称

软件包的基本名称，应该与 SPEC 文件名匹配。

版本

软件的上游版本。

Release

发布此软件版本的次数。通常，将初始值设为 1%{?dist}，并在每个新版软件包中递增。当软件的一个新版本构建时，将重置为 1。

概述

软件包的一个简短总结.

许可证

所打包的软件许可证。

URL

有关程序的更多信息的完整 URL。大多数情况下，这是所打包软件的上游项目网站。

Source0

上游源代码的压缩存档的路径或 URL（未修补，补丁会在其他位置处理）。这应该指向该存档的可访问且可靠的存储，例如上游页面而不是打包程序的本地存储。如果需要，可以添加更多 SourceX 指令，每次递增数字，例如： Source1、Source2、Source3 等。

Patch

应用于源代码的第一个补丁的名称（如有必要）。

该指令可以通过两种方式应用：带有或不带补丁末尾的数字。

如果没有指定数字，则会在内部分配一个条目。也可以使用 Patch0, Patch1, Patch2, Patch3 明确提供数字。

这些补丁可以通过使用 %patch0、%patch1、%patch2 宏等应用。宏在 RPM SPEC 文件的 Body 部分中的 %prep 指令中应用。或者，您可以使用 %autopatch 宏，以 SPEC 文件中提供的顺序自动应用所有补丁。

BuildArch

如果软件包没有架构依赖，例如，如果完全使用解释编程语言编写，则将其设置为 BuildArch: noarch。如果没有设置，软件包会自动继承构建机器的架构，如 x86_64。

BuildRequires

使用编译语言构建程序所需的逗号或空格分开的软件包列表。BuildRequires 可以有多个条目，每个条目都在 SPEC 文件中的独立的行中。

Requires

安装之后，软件需要以逗号或空格分开的软件包列表。Requires 可以有多个条目，每个条目都在 SPEC 文件中的独立的行中。

ExcludeArch

如果某一软件不能在特定处理器架构上运行，您可以在此处排除该架构。

Conflicts

Conflicts 与 Requires 相反。如果存在与 Conflicts 匹配的软件包，则软件包是否可以安装取决于，带有 Conflict 标签的软件包是否位于已安装的软件包中，还是准备要被安装到的软件包中。

Obsoletes

这个指令会改变更新的工作方式，具体取决于 rpm 命令是否直接在命令行中使用，或者更新是由更新还是依赖项解析程序执行。当在命令行中使用时，RPM 会删除与正在安装的软件包的过时匹配的所有软件包。当使用更新或依赖项解析器时，包含匹配 Obsoletes: 的软件包会作为更新添加并替换匹配的软件包。

Provides

如果向软件包添加了 Provides，则软件包可以通过名称以外的依赖项引用。

%description

RPM 中打包的软件的完整描述。此描述可跨越多行，并且可以分为几个段落。

%prep

用于准备要构建的软件的命令或一系列命令，例如，在 Source0 中解压缩存档。此指令可以包含 shell 脚本。

%build

将软件构建到机器代码（用于编译的语言）或字节代码（用于某些解释语言）的命令或一系列命令。

%install

命令或一系列命令，用于将所需的构建工件从 %builddir （构建发生位置）复制到 %buildroot 目录（其中包含要打包文件的目录结构）。这通常意味着将文件从 ~/rpmbuild/BUILD 复制到 ~/rpmbuild/BUILDROOT，并在 ~/rpmbuild/BUILDROOT 中创建必要的目录。这仅在创建软件包时运行，而不是当最终用户安装软件包时。详情请查看 第 3.2 节 “使用 SPEC 文件”。

%check

用于测试软件的命令或一系列命令。这通常包括单元测试等内容。

%files

将在最终用户系统中安装的文件列表。

%changelog

在不同 Version 或 Release 之间软件包所发生的更改记录。