18、在非 Red Hat Linux 系统上使用 RPM 的全面指南

在非 Red Hat Linux 系统上使用 RPM 的全面指南

1. RPM 在 Linux 中的发展与现状

最初，RPM 代表 Red Hat Package Manager，但如今它已被大多数主流 Linux 发行版采用，其含义也演变为 RPM Package Manager。同时，RPM 包格式正被 Linux 标准基础（LSB）所接纳，LSB 定义了一系列标准，有助于维护所有 Linux 发行版的兼容性。更多关于 LSB 的信息可访问 www.linuxbase.org 。

2. 安装 RPM 包时的故障排除

在其他版本的 Linux 上安装 RPM 包时，主要会遇到以下几个问题：
- RPM 版本差异 ：不同的 Linux 发行版可能使用不同版本的 RPM。可以使用 rpm --version 命令查看当前系统使用的 RPM 版本。例如：

$ rpm --version
RPM version 4.1

若要在不同版本的 RPM 系统间安装软件包，可能需要处理依赖检查和签名验证的问题。比如，在 RPM 3.x 系统上安装 RPM 4.x 构建的软件包时，可使用 --nodeps 选项禁用依赖检查，但之后需手动确认依赖项是否满足。而在 RPM 4.x 系统上安装 RPM 3.x 构建的软件包时，可使用 --nosignature 选项禁用签名检查。
- 软件包划分差异 ：不同 Linux 发行版对大型应用程序的包划分没有统一标准，这可能导致包之间的依赖关系不同。若依赖的是发行版提供的软件包，可能会出现包不存在或不需要的情况；若依赖的是文件，尤其是共享库，只要文件位置相同，一般不会有问题。解决此问题的方法是使用 --nodeps 选项关闭依赖检查，然后手动确认系统是否满足所有依赖。
- 依赖问题 ：依赖问题是最棘手的部分，从安装必要软件包到处理共享库版本或特定 Perl 模块等复杂问题都可能涉及。首先要确保没有遗漏提供正确依赖的必要 RPM 包，可从 Linux 供应商的网站下载特定于发行版的软件包。若依赖的是系统共享库，可重新编译软件包以使用系统库的不同版本；若依赖的是应用程序共享库，则需安装拥有该库的软件包并尝试从源 RPM 重新构建。可使用 rpm -qf 命令查询文件所属的软件包，使用 rpm -q --whatprovides 命令查询提供特定功能的软件包。
- 安装位置差异 ：Linux 供应商可以将软件安装在任何位置，这可能导致文件依赖和软件包安装位置的问题。可以使用 --badreloc 选项尝试重新定位软件包，但该选项不会修改文件内容，因此可能需要编辑包含硬编码路径的脚本文件或从源 RPM 重新构建软件包。

3. 构建 RPM 包时的问题处理

构建 RPM 包时，也会遇到一些与安装时类似的问题，同时还有一些仅在构建时出现的问题。
- 编写特定于发行版的软件包 ：为了应对不同 Linux 发行版在 RPM 使用上的差异，可以为每个支持的发行版创建单独的软件包。也可以将差异融入宏中，使用单个 spec 文件，但有时 spec 文件会变得过于复杂，此时可能需要为每个发行版创建多个 spec 文件。可以通过查看包含特定于发行版的 RPM 配置的软件包来了解发行版定义的宏，例如在 Red Hat Linux 系统上，可以使用 rpm -ql redhat-rpm-config 命令查看 Red Hat 定义的宏。

$ rpm -ql redhat-rpm-config
/usr/lib/rpm/redhat
/usr/lib/rpm/redhat/brp-compress
/usr/lib/rpm/redhat/brp-redhat
/usr/lib/rpm/redhat/brp-sparc64-linux
/usr/lib/rpm/redhat/brp-strip
/usr/lib/rpm/redhat/brp-strip-comment-note
/usr/lib/rpm/redhat/brp-strip-shared
/usr/lib/rpm/redhat/find-lang.sh
/usr/lib/rpm/redhat/find-provides
/usr/lib/rpm/redhat/find-requires
/usr/lib/rpm/redhat/macros
/usr/lib/rpm/redhat/perl.prov
/usr/lib/rpm/redhat/perl.req
/usr/lib/rpm/redhat/rpmrc

• 处理自动依赖生成 ：RPM 4.x 版本具有自动生成依赖的功能，但由于不同的包布局、目录结构或 RPM 版本，可能需要禁用部分或全部自动依赖生成。可以在 spec 文件中添加 Autoreq: 0 指令来禁用自动依赖生成，但这需要手动使用 Requires: 标签定义所有需求。更好的方法是覆盖 %_find_requires 和 %_find_provides 宏，以过滤掉导致问题的依赖。

$ rpm --eval "%_find_provides"
/usr/lib/rpm/find-provides
$ rpm --eval "%_find_requires"
/usr/lib/rpm/find-requires

• 处理不同的宏 ：不同的 Linux 供应商在 RPM 设置中定义了不同的宏，包括宏的值和名称。因此，在构建 RPM 包时，最好定义自己的本地宏集，并尽可能依赖自己的 RPM 宏。可以使用条件语句在 spec 文件中根据供应商特定的宏定义自己的宏。
• 制作可重定位的软件包 ：应使软件包可重定位，以便用户可以将其安装到任何目录。可以在 spec 文件中使用 %{_bindir} 宏，并定义宏来指定依赖项的位置，然后使用 --define 选项为这些宏赋值。

4. 创建 RPM 构建环境

若要为多个版本的 Linux 构建 RPM 包，可以设置一个能清晰分离大多数特定于供应商问题的 RPM 构建环境。关键问题包括：
- 检测供应商 ：可以通过查询包含供应商名称的特殊文件（如 /etc/vendor-release ）或软件包（如 vendor-release ）来检测 Linux 供应商，也可以手动定义一个宏来指定供应商。

$ more /etc/redhat-release
Red Hat Linux release 8.0 (Psyche)
$ rpm -q redhat-release
redhat-release-8.0-8
# rpmbuild -ba --define 'linuxVendor suse'

• 使用宏定义干净的构建过程 ：可以使用 %if...%endif 条件语句和命令行选项（如 --with 、 --without 和 --target ）来控制构建过程。例如：

%if %(old_Sx) && %(old_6x)
%(error: You cannot build for .Sx and .6x at the same time)
%quit
%endif
%if %(old_Sx)
%define bSx 1
%undefine b6x
%endif
%if %(old_6x)
%define b6x 1
%undefine bSx
%endif
%if %(build6x)
Requires: util-linux, pam >= 0.66-5
%else
Requires: util-linux, pam >= 0.75-37, /etc/pam.d/system-auth
%endif
$ rpmbuild -be --with ssh filename.spec
$ rpmbuild -be --target ppc-ibm-aix /usr/src/redhat/SPECS/jikes.spec

• 处理不同的依赖 ：根据不同的依赖情况，采取相应的解决方法，如重新编译软件包、安装拥有依赖库的软件包等。

5. 兼容性和胶水包

并非所有 Linux 发行版都是相同的，宏不能解决所有差异问题。兼容性包可以在不支持旧 API 的新系统上提供旧 API，通常以 compat- 开头命名。胶水包则可以提供某些 Linux 发行版缺少的依赖项。关键是要将兼容性和胶水包与主应用程序包分开，让用户根据自己的 Linux 发行版按需安装。

6. 处理签名问题

在 SuSE Linux 或基于 UnitedLinux 1.0 的任何 Linux 系统上，RPM 包使用 OpenPGP 版本 4 签名，而不是 RPM 4.1 中使用的版本 3。因此，需要使用非 RPM 方法提取签名，然后使用 gpg 验证签名。

7. 处理非 RPM 基于的 Linux 版本

不支持 RPM 的主要 Linux 发行版是 Debian GNU/Linux 系列和 Slackware Linux。可以使用名为 alien 的包转换工具在 RPM 系统和其他包格式（如 dpkg、sip 和 tgz）之间进行转换。

8. RPM 标准化

RPM 正被考虑纳入 Linux 标准基础（LSB）1.3，这将为 Linux 发行版定义标准的打包格式，随着时间的推移减少发行版之间的 RPM 差异。此外，文件系统层次结构标准（FHS）和许多 Linux 供应商对 RPM 的采用也有助于统一多样化的 Linux 发行版。FHS 定义了 Linux 系统上所有上层目录的用途，为供应商和应用程序开发者提供了更好的软件安装位置指导。更多关于 FHS 的信息可访问 www.pathname.com/fhs 。

综上所述，在不同的 Linux 发行版上使用和构建 RPM 包时，会遇到各种问题，但通过合理的方法和技巧，可以有效地解决这些问题。同时，随着标准化工作的推进，不同发行版之间的差异将逐渐减少，跨平台 RPM 包的创建也将变得更加容易。

下面是一个简单的 mermaid 流程图，展示了在非 Red Hat Linux 系统上安装 RPM 包的基本流程：

graph TD;
    A[开始] --> B[检查 RPM 版本];
    B --> C{版本是否兼容};
    C -- 是 --> D[检查依赖关系];
    C -- 否 --> E[处理版本差异];
    D --> F{依赖是否满足};
    F -- 是 --> G[安装 RPM 包];
    F -- 否 --> H[解决依赖问题];
    E --> D;
    H --> D;
    G --> I[结束];

另外，为了更清晰地展示不同问题的解决方法，我们可以使用一个表格：
| 问题类型 | 解决方法 |
| ---- | ---- |
| RPM 版本差异 | 使用 rpm --version 查看版本，根据情况使用 --nodeps 或 --nosignature 选项 |
| 软件包划分差异 | 使用 --nodeps 选项关闭依赖检查，手动确认依赖 |
| 依赖问题 | 下载特定于发行版的软件包，重新编译软件包，安装拥有依赖库的软件包 |
| 安装位置差异 | 使用 --badreloc 选项重新定位软件包，编辑脚本文件或从源 RPM 重新构建 |
| 签名问题 | 使用非 RPM 方法提取签名，使用 gpg 验证签名 |
| 非 RPM 基于的 Linux 版本 | 使用 alien 工具进行包转换 |

在非 Red Hat Linux 系统上使用 RPM 的全面指南（续）

9. 不同 Linux 发行版 RPM 使用差异总结

不同 Linux 发行版在使用 RPM 时存在诸多差异，主要体现在以下几个方面：
- RPM 版本 ：各发行版使用的 RPM 版本不同，可能导致依赖检查和签名验证等问题。
- 软件包划分 ：对大型应用程序的包划分缺乏统一标准，使得包之间的依赖关系存在差异。
- 依赖问题 ：包括共享库版本、特定 Perl 模块等复杂的依赖情况。
- 安装位置 ：软件安装位置不固定，可能影响文件依赖和软件包的正常使用。
- 宏定义 ：不同供应商定义的宏不同，包括宏的值和名称。

以下是这些差异的详细对比表格：
| 差异方面 | 具体表现 | 影响 |
| ---- | ---- | ---- |
| RPM 版本 | 不同发行版使用不同版本的 RPM | 安装不同版本构建的软件包时需处理依赖和签名问题 |
| 软件包划分 | 对大型应用程序的包划分无统一标准 | 依赖关系可能不同，需手动确认依赖 |
| 依赖问题 | 涉及共享库版本、特定模块等 | 可能导致软件包安装失败，需重新编译或安装依赖库 |
| 安装位置 | 软件可安装在任意位置 | 可能影响文件依赖，需重新定位或编辑脚本文件 |
| 宏定义 | 不同供应商定义不同的宏 | 构建 RPM 包时需定义自己的本地宏集 |

10. 构建 RPM 包的最佳实践

为了在不同的 Linux 发行版上顺利构建和使用 RPM 包，可遵循以下最佳实践：
- 定义本地宏集 ：在构建 RPM 包时，定义自己的本地宏集，减少对供应商特定宏的依赖。可使用条件语句根据供应商特定宏定义自己的宏。
- 制作可重定位包 ：使软件包可重定位，方便用户安装到任意目录。使用 %{_bindir} 宏，并定义宏指定依赖项位置，通过 --define 选项赋值。
- 分离兼容性和胶水包 ：将兼容性和胶水包与主应用程序包分开，让用户按需安装，降低不同发行版差异的影响。
- 标准化构建环境 ：创建标准化的 RPM 构建环境，清晰分离特定于供应商的问题，便于为多个版本的 Linux 构建 RPM 包。

11. 未来趋势与展望

随着 Linux 标准基础（LSB）和文件系统层次结构标准（FHS）的推进，不同 Linux 发行版之间的差异将逐渐减少。RPM 作为一种广泛使用的包管理工具，将在标准化过程中发挥重要作用。未来，跨平台 RPM 包的创建将变得更加容易，开发者可以更方便地为不同的 Linux 发行版提供软件包。

以下是一个 mermaid 流程图，展示了未来 RPM 标准化的趋势：

graph TD;
    A[当前不同发行版 RPM 差异大] --> B[LSB 和 FHS 推进];
    B --> C[发行版差异逐渐减少];
    C --> D[跨平台 RPM 包创建更易];
    D --> E[开发者更方便提供软件包];

12. 总结

在非 Red Hat Linux 系统上使用和构建 RPM 包时，会遇到多种问题，如 RPM 版本差异、软件包划分差异、依赖问题、安装位置差异等。通过采取合适的解决方法，如处理版本和依赖问题、制作可重定位包、使用兼容性和胶水包等，可以有效解决这些问题。同时，随着 LSB 和 FHS 等标准化工作的推进，不同发行版之间的 RPM 差异将逐渐缩小，跨平台 RPM 包的创建将更加便捷。

为了帮助大家更好地理解和应用这些知识，下面总结了一些关键操作步骤的列表：
1. 检查 RPM 版本 ：使用 rpm --version 命令查看当前系统使用的 RPM 版本。
2. 处理依赖问题 ：
- 若依赖系统共享库，可尝试重新编译软件包。
- 若依赖应用程序共享库，安装拥有该库的软件包并尝试从源 RPM 重新构建。
- 使用 rpm -qf 命令查询文件所属软件包，使用 rpm -q --whatprovides 命令查询提供特定功能的软件包。
3. 构建 RPM 包 ：
- 定义自己的本地宏集，减少对供应商特定宏的依赖。
- 制作可重定位包，使用 %{_bindir} 宏和 --define 选项指定依赖项位置。
4. 处理非 RPM 基于的 Linux 版本 ：使用 alien 工具在 RPM 系统和其他包格式之间进行转换。
5. 验证签名 ：在 SuSE Linux 或基于 UnitedLinux 1.0 的系统上，使用非 RPM 方法提取签名，然后用 gpg 验证签名。

通过遵循这些步骤和最佳实践，开发者可以在不同的 Linux 发行版上更高效地使用和构建 RPM 包。