RPM包与源码包：深入剖析 Linux 软件安装的两种核心方式

目录#

引言
理解 RPM 包
- 2.1. 什么是 RPM？结构与工作原理
- 2.2. RPM 安装的核心优势
- 2.3. RPM 安装的局限性与挑战
- 2.4. RPM 工具链简介 (rpm, yum/dnf)
理解源码包
- 3.1. 什么是源码包？结构与典型内容
- 3.2. 源码安装的核心优势
- 3.3. 源码安装的局限性与挑战
- 3.4. 源码安装的标准流程 (./configure, make, make install)
关键对比维度：RPM vs. 源码
- 4.1. 易用性与便利性
- 4.2. 依赖管理
- 4.3. 定制化与灵活性
- 4.4. 性能优化
- 4.5. 安全性与更新
- 4.6. 系统集成与维护性
- 4.7. 资源消耗 (时间/空间/带宽)
常见实践与最佳实践
- 5.1. RPM 安装的最佳实践
- 5.2. 源码安装的最佳实践
- 5.3. 混合实践：在 RPM 基础上构建自定义包 (SRPM)
- 5.4. 虚拟环境与容器化影响
何时选择何种方式？决策指南
实例场景分析
- 7.1. 安装基础服务器软件 (如 Nginx, MariaDB)
- 7.2. 安装开发工具/库 (如 Python, GCC)
- 7.3. 安装特定版本或定制软件 (如最新 Nginx 测试版)
结论
参考资源

2. 理解 RPM 包#

2.1. 什么是 RPM？结构与工作原理#

本质： RPM 是一种标准的软件打包格式，包含了预编译好的二进制程序、配置文件、文档、依赖关系信息、安装/卸载脚本等元数据，以及用于验证完整性的签名（可选）。文件扩展名通常为 .rpm。
结构： 一个 RPM 文件像一个压缩的存档文件，内部组织遵循特定结构（使用 rpm2cpio 和 cpio 工具可查看）。关键组件包括：
- 二进制可执行文件： 软件的核心，开箱即用。
- 配置文件 (*.conf, *.cfg)： 通常放在 /etc 或其子目录。
- 文档 (*.txt, *.md, man pages)： 放在 /usr/share/doc 和 /usr/share/man。
- 库文件 (*.so)： 放在 /usr/lib 或 /usr/lib64。
- 元数据 (SPECFILE 信息)： 包含软件名称、版本、发行号、描述、依赖列表（Requires）、提供内容（Provides）、文件清单等。
- 脚本 (%pre, %post, %preun, %postun)： 在安装/卸载前后自动执行的脚本。

2.2. RPM 安装的核心优势#

易用性与速度： 安装 (rpm -i package.rpm or dnf install package) 和卸载 (rpm -e package or dnf remove package) 过程极其快速简便。无需编译，省时省力。
依赖管理自动化： RPM 系统（尤其是 yum/dnf）能自动解析和安装软件所需的库和其他依赖包（Requires:），是处理复杂依赖链最强大的武器。
标准化与一致性： 所有 RPM 包遵循相同的结构和元数据规范，确保安装位置、配置路径、服务管理方式的一致性。这使得系统管理更规范、可预测。
完整性验证与来源可信： 官方仓库的 RPM 通常带有 GPG 签名。用户可以在安装前验证包的来源和内容完整性 (rpm --checksig package.rpm, rpm -K package.rpm)，增强安全性。系统 RPM 数据库 (/var/lib/rpm) 记录所有安装的包及其文件。
简便的升级与降级： 系统提供的工具 (yum update/dnf upgrade, yum downgrade/dnf downgrade) 使得升级到新版本或回滚到旧版本相对直接。升级包通常包含安全修复和功能改进。
集中化管理： 通过仓库（Repository）分发，管理员可以轻松地在大量服务器上部署、更新相同的软件包。
社区与官方支持： 来自发行版官方仓库的 RPM 经过了测试，通常更稳定，有社区或商业支持保障。

2.3. RPM 安装的局限性与挑战#

定制化限制： 安装的软件功能是打包者预先配置和编译好的。你无法轻松地启用/禁用特定的编译选项（如特定功能模块、调试信息、优化级别）或应用源码级补丁。
版本滞后： 官方仓库为了稳定性和测试周期，提供的软件版本可能不是最新的。获取最新稳定版或特定旧版有时需要第三方仓库（如 EPEL、Remi）或手动下载 RPM，增加了复杂性。
兼容性问题： 预编译的二进制包通常针对特定发行版版本（如 CentOS 7, CentOS 8 Stream）及其基础库（如 glibc）进行编译。在较旧或较新的系统上安装为其他版本设计的 RPM 可能导致兼容性问题或损坏系统（“dependency hell”）。
第三方仓库风险： 使用非官方仓库是获取较新或特殊软件的常见方式，但需评估仓库的信任度、兼容性、更新策略以及其与官方仓库的潜在冲突。
非仓库 RPM 的安全隐患： 手动下载单个 RPM 文件并安装，跳过了仓库的签名验证和安全审查过程，存在安全风险。

2.4. RPM 工具链简介#

rpm： 基础命令行工具。用于查询包信息 (rpm -q), 安装 (rpm -i), 升级 (rpm -U), 卸载 (rpm -e), 验证文件 (rpm -V), 导入密钥 (rpm --import) 等。
yum (Yellowdog Updater Modified)： 更高级的命令行工具（CentOS/RHEL 7 及更早）。自动解决依赖关系并从仓库安装软件 (yum install/update/remove/clean 等）。
dnf (Dandified YUM)： yum 的现代化后继者（Fedora、CentOS 8/RHEL 8+、openSUSE）。性能更好，依赖解析更健壮，API 更友好 (dnf install/update/remove/search group install 等)。现在已基本取代 yum。
GUI 工具： GNOME Software/KDE Discover (部分集成), dnfdragora 等图形化包管理器。

3. 理解源码包#

3.1. 什么是源码包？结构与典型内容#

本质： 包含软件项目的原始源代码文件（通常为 C、C++、Go、Rust 等编写）以及其他构建所需文件的压缩包（*.tar.gz, *.tar.bz2, *.tar.xz, *.zip）。内容未经编译。
典型内容：
- 源代码文件 (.c, .cpp, .py, .rs, .go, .h 等)
- 构建系统配置文件：
  - configure 脚本 (Autotools 项目): 检测系统环境并生成 Makefile。
  - CMakeLists.txt (CMake 项目): 描述构建规则的跨平台配置文件（需要 cmake 工具生成 Makefile 或其他项目文件）。
  - Makefile (手动编写或其他系统生成): 直接指定编译规则和依赖。
- 文档 (README, INSTALL, COPYING/LICENSE)
- 测试文件 (tests/)
- 贡献指南 (CONTRIBUTING.md)

3.2. 源码安装的核心优势#

完全的定制化控制：
- 可以通过 ./configure 选项（或编辑 CMakeLists.txt/Makefile）启用或禁用特定功能（如模块、数据库支持、日志驱动）。
- 可以调整优化编译选项 (CFLAGS, CXXFLAGS) 进行特定于硬件的性能调优（如针对特定 CPU 架构的优化 -march=native)。
- 可以轻松应用第三方补丁（patch 命令）或直接修改源码来满足特殊需求或修复问题。
获取最新版本或特定版本： 直接从软件官网或 GitHub 仓库下载源代码，可以立即获得最新稳定版、测试版（Beta/RC）、甚至是开发分支（git clone）或任意的历史版本，紧跟开发进度或满足项目对特定旧版本的依赖。
增强理解： 编译过程迫使开发者/管理员接触构建系统和依赖关系，有助于更深入地理解软件内部工作原理。
潜在的兼容性： 如果编译环境设置正确（包含必要版本的头文件和库），源码编译可以在发行版版本跨度较大的系统上成功运行（比二进制 RPM 范围更广），尤其适用于非主流发行版或特殊定制系统。
独立性： 不依赖于特定发行版的仓库或打包策略。

3.3. 源码安装的局限性与挑战#

过程复杂耗时： 需要手动下载源码、安装编译工具链（gcc, make, cmake, autoconf, automake 等）、解决开发库依赖 (*-devel RPMs)、运行 configure/cmake、执行 make 编译（可能很慢）、最后 make install 安装。步骤多，易出错。
手动依赖管理 (依赖地狱)：
- 编译所需的头文件和开发库文件（通常是对应 RPM 的 *-devel 包）必须手动安装，且版本要求通常更严格。
- 如果依赖缺失或版本不匹配，configure 或 make 会报错，需要开发者像解谜一样逐个查找并安装正确版本的开发包，极其繁琐耗时。
- 深度依赖链问题可能非常棘手（如 A 需要新版 B，但 B 需要新版 C，而新版 C 与系统中已安装的其他软件冲突）。
缺乏系统集成与跟踪：
- make install 通常将文件直接复制到 /usr/local（默认，可更改），绕过了系统的 RPM 数据库。
- 卸载困难：没有标准的卸载命令。通常需要保留 makefile 并运行 make uninstall（如果构建系统支持且你记得保存构建目录），或者必须手动删除所有安装的文件（易出错、易残留）。
- 无法由系统包管理器 (dnf/yum) 统一管理、更新或跟踪。
安全更新负担： 管理员需主动关注软件的安全公告（CVE），及时下载新源码包，重新编译、安装并测试。自动化程度远低于 RPM 的系统级自动更新。
潜在的系统不稳定： 如果安装到 /usr 或 / 下系统目录（非 /usr/local），可能覆盖或干扰系统关键文件或 RPM 安装的包，导致系统崩溃或不可预测的行为。/usr/local 相对安全。
调试符号与大小： 默认编译通常包含调试符号，生成的二进制文件更大（除非刻意剔除）。

3.4. 源码安装的标准流程#

# 示例：使用 Autotools (./configure) 的项目
wget https://example.com/software-X.Y.Z.tar.gz   # 下载源码包
tar xzvf software-X.Y.Z.tar.gz                   # 解压
cd software-X.Y.Z                                # 进入源码目录
 
# 安装编译依赖（通常需多次尝试解决报错）
sudo dnf install gcc make autoconf automake libtool zlib-devel openssl-devel ... # 查找项目文档或报错信息确定所需开发包
 
./configure --prefix=/usr/local \                # 指定安装前缀（强烈建议）
             --enable-feature-A \                # 启用特定功能
             --disable-feature-B \               # 禁用特定功能
             CFLAGS="-O2 -march=native"          # 自定义编译优化选项 (可选)
# (根据 configure 输出安装缺少的依赖)
 
make                                             # 编译源代码 (可能耗时)
sudo make install                                # 安装到系统 (通常在 /usr/local)
 
# （可选）安装后清理编译环境（会移除源码目录，确保已安装成功）
# cd .. && rm -rf software-X.Y.Z
 
# 卸载（如果构建目录还在且支持）
cd software-X.Y.Z
sudo make uninstall

# 示例：使用 CMake 的项目
wget ...
tar xzvf ...
cd software-X.Y.Z
mkdir build && cd build                          # 推荐使用单独构建目录
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local \      # 设置安装前缀
         -DENABLE_FEATURE_A=ON \
         -DBUILD_TESTING=OFF \
         -DCMAKE_BUILD_TYPE=Release
make
sudo make install

4. 关键对比维度：RPM vs. 源码#

维度	RPM 包 (使用 yum/dnf)	源码包 (手动编译安装)
安装速度	极快 (预编译二进制)	非常慢 (需要下载源码、配置、编译)
安装便利性	极简便 (一行命令)	复杂繁琐 (多个步骤，需手动解决依赖)
依赖管理	自动化、高效 (yum/dnf 自动解决)	手动、困难、耗时 ("依赖地狱"，需安装`*-devel`包)
定制化能力	有限 (固定功能集)	极高 (可任意调整编译选项、启用/禁用功能、打补丁)
性能优化	通用优化 (通常是 `-O2`，针对x86-64通用)	可深度优化 (针对特定 CPU 如 `-march=native`，调整优化级别)
软件版本	通常滞后 (稳定优先，通过仓库更新)	通常最新或灵活选择 (可直达官网下载最新稳定/测试/任意历史版本)
系统集成	优秀 (文件位置标准化，记录在数据库)	差 (`make install` 多放于 `/usr/local`，无系统跟踪)
管理维护	方便 (统一查询/更新/卸载/验证)	困难 (升级需手动重复编译；卸载困难或无标准方法；文件易残留)
安全性更新	便利 (可自动/半自动更新安全补丁包)	负担重 (需主动关注公告，手动下载、编译、安装更新)
来源信任与验证	良好 (支持 GPG 签名仓库验证)	需用户判断 (依赖源码来源可信度；编译工具链安全)
资源消耗 (编译时)	低 (仅下载)	高 (CPU、内存、硬盘空间)
跨发行版兼容性	低 (针对特定发行版编译)	相对较高 (正确配置开发环境和依赖后，可跨版本/非主流系统编译成功)
学习曲线	低 (易学易用)	高 (需理解构建系统、编译选项、依赖管理)
适合场景	生产服务器、桌面系统、绝大多数标准化软件安装	需要深度定制、最新功能、特定版本、性能调优、研究源码或在特殊环境部署的软件。开发环境有时也需源码编译库。

5. 常见实践与最佳实践#

5.1. RPM 安装的最佳实践#

优先使用官方仓库： dnf install @package-group / yum groupinstall 'group-name'。信任度高，集成好。
启用可信的第三方仓库： 如 EPEL (Extra Packages for Enterprise Linux)，提供大量高质量补充包。仔细阅读仓库启用说明。确保 dnf repolist 显示信任的仓库。
验证仓库元数据： 确保 /etc/yum.repos.d/*.repo 文件中的 gpgcheck=1 启用，并使用 dnf update --refresh 或 yum makecache 保持元数据最新。
使用 dnf/yum 而非 rpm 处理依赖： 避免使用 rpm -i 直接安装单个未解决的 RPM，除非能手动解决所有依赖（极其困难）。使用 dnf install ./local.rpm 更安全。
利用组和元包： 安装功能组（如 dnf groupinstall "Development Tools"）或元包（如 @mysql-server) 简化依赖复杂的软件集安装。
保持更新： 定期运行 dnf update / yum update 应用安全补丁和功能更新。
检查包信息： 使用 dnf info / yum info, rpm -qi, rpm -ql 查看包详细信息和文件列表。
管理仓库优先级/版本锁定 (谨慎)： 使用 dnf-plugins-core (如 dnf versionlock) 或 yum-plugin-versionlock 锁定关键包的版本。小心处理仓库优先级（priority= in .repo files）以避免冲突。
备份和快照： 在生产环境更改（如大版本更新）前，进行虚拟机快照或系统备份。

5.2. 源码安装的最佳实践#

使用 /usr/local： 这是系统为本地编译软件设计的位置，避免干扰 /usr 下的系统包文件。显式设置 --prefix=/usr/local (Autotools) 或 -DCMAKE_INSTALL_PREFIX=/usr/local (CMake)。
优先安装 *-devel 包： 使用 dnf/yum 安装所需的开发库依赖包 (...-devel) 和构建工具 (gcc, make, cmake, autoconf, etc.)。这是解决依赖地狱最关键的实践！
查阅文档 (README, INSTALL)： 第一步永远是阅读软件自带的安装说明文档，了解依赖、配置选项和特殊步骤。
使用源码管理器 (可选但推荐)： 对于版本控制下的源码（如 git clone），更容易更新、回滚和打补丁。
创建构建目录 (CMake)： 对于 CMake 项目，在源码目录外创建单独的 build 目录，方便清理且不污染源码。
保存构建目录： 保留解压后的源码目录和配置 (config.log, config.status) 至少到成功安装并测试后，便于重新安装（增补编译）或尝试卸载 (make uninstall）。
考虑隔离环境：
- 用户目录 (~/bin, ~/.local)： 为单用户程序设置 --prefix=$HOME/.local。将 $HOME/.local/bin 加入 $PATH。
- 版本管理器： 像 pyenv (Python), nvm (Node.js), rvm/rbenv (Ruby) 等工具会自动处理源码编译和环境隔离。
- 容器/Docker： 在容器内编译安装，避免污染宿主机系统，便于分发和销毁。
记录步骤： 将编译选项和依赖安装步骤写成脚本 (install_software_X.sh)，方便重现（尤其在多台机器安装时）和文档记录。
安全更新： 订阅软件的邮件列表、GitHub Releases 或 CVE 通知服务，及时跟进源码安全更新。

5.3. 混合实践：在 RPM 基础上构建自定义包 (SRPM)#

方法： 下载源码 RPM (SRPM, .src.rpm) -> 安装依赖 (dnf builddep ...) -> 修改 SPEC 文件 (.spec) 或打补丁 -> 重新构建生成自定义的 RPM (rpmbuild -ba ...)。
优点：
- 继承 RPM 的依赖管理优势。
- 保留了定制化的能力（修改编译选项、打补丁）。
- 生成的是标准的、可由 dnf/yum 管理的 RPM 包。
- 有明确的构建规范（SPEC文件）。
缺点： 需要学习 .spec 文件语法、RPM 构建工具链 (rpmbuild) 和打包知识，门槛比纯手动编译更高。适合有一定 RPM 打包经验的管理员或希望将定制软件打包分发的场景。

5.4. 虚拟环境与容器化影响#

虚拟环境 (Python venv/virtualenv, Ruby bundle with path)： 通常用于隔离特定项目的语言级依赖（库）。这类环境内部仍可通过 pip install --no-binary :all: 强制源码编译安装库（解决特定二进制兼容问题），但从系统角度看，主 Python/Ruby 解释器本身仍推荐 RPM 安装以保证基础稳定。
容器化 (Docker/Podman)： 大大简化了软件部署的复杂性。容器镜像构建过程 (Dockerfile) 提供了一个理想环境使用源码编译安装软件：
- 清晰地列出所有编译依赖 (dnf install -y gcc make ... devel_packages)。
- 设定明确的安装步骤和选项。
- 生成的镜像独立于宿主机系统。
- 便于分发和版本控制。
- 容器内源码编译成为一种高度推荐的最佳实践，因为它完美解决了定制化需求和污染宿主系统的问题。

6. 何时选择何种方式？决策指南#

选择 RPM 包（优先）如果：

目标是生产服务器稳定运行、安全维护方便。
软件存在于官方或受信任的第三方仓库中。
标准功能和性能配置已满足需求，无需深度定制。
系统标准化、可预测性和易于管理（批量更新/卸载）是首要考虑。
你希望由发行版提供安全更新。
你需要快速安装软件。
你不想处理复杂的编译依赖问题。

选择源码包（有充分理由时）如果：

需要软件的特定版本（最新、测试版、或仓库中没有的旧版）。
需要深度定制软件功能（启用/禁用特定模块、特性、驱动）。
需要针对特定 CPU 架构（硬件）进行极致性能优化（如 HPC）。
需要应用非官方补丁或修改源码本身。
在特殊或非主流 Linux 环境部署，且无法获得兼容的 RPM 包。
软件本身不是通过二进制包分发（只有源码）。
作为学习、研究或调试软件内部机制的一部分（开发环境常见）。
你愿意且有能力投入时间处理编译依赖、维护更新负担和安全风险管理，或在容器中进行编译隔离。

核心原则总结：

无脑优先 RPM： 对于绝大多数标准服务器软件、基础工具、核心库、桌面应用，优先使用 dnf install / yum install。这是生产环境的黄金标准。
慎重评估选源码： 只有当 RPM 无法满足上述特殊需求（特定版本、深度定制、极致优化）时，才转向源码编译安装。必须有明确的、RPM 无法解决的强需求作为理由。
隔离环境是朋友： 如果必须源码安装，强烈建议在容器内或用户隔离目录 (/usr/local 或 $HOME/.local) 中进行，并做好文档化记录。使用 dnf/yum 安装必要的 *-devel 包是编译前最关键且最耗时的准备步骤。

7. 实例场景分析#

7.1. 安装基础服务器软件 (如 Nginx, MariaDB)#

推荐方式：RPM
- 理由： 官方仓库提供稳定、经过测试且持续维护的版本。依赖管理完全自动化 (dnf install nginx / dnf install mariadb-server)。系统集成良好（服务管理 systemctl start/stop/enable nginx/mariadb，配置文件在 /etc/nginx, /etc/my.cnf.d 等标准位置）。安全更新通过 dnf update 便捷获取。高度标准化，便于批量管理。
- 源码适用情况： 除非你需要某个仅在源码版本中启用的非常特殊的第三方模块（官方包未编译）或者必须使用最新未发布的特性分支，否则强烈不推荐。

7.2. 安装开发工具/库 (如 Python, GCC)#

GCC：强烈推荐 RPM (dnf install gcc). 它是基础编译链，通常由发行版严格维护版本兼容性。手动编译 GCC 极其复杂且容易出错。
Python：
- 系统 Python (如 /usr/bin/python3)：务必使用 RPM。 发行版核心组件和服务依赖它。修改它风险极高！
- 为特定项目使用较新/自定义Python：推荐版本管理器 (pyenv)。 它在你的用户空间下从源码编译安装特定 Python 版本（pyenv install 3.12.1），隔离于系统 Python，并提供高效切换。这是兼顾隔离、定制、版本控制和安全的源码安装最佳实践变种。避免手动 ./configure && make && make install 到 /usr/local/pythonX.Y 并与系统包冲突。
- 特定库/工具链的依赖（如 TensorFlow）： 通常也是通过版本管理或虚拟环境内的 pip 安装（可能涉及部分后端库的源码编译）。

7.3. 安装特定版本或定制软件 (如最新 Nginx 测试版)#

推荐方式：源码包（+ 谨慎操作或构建自定义 RPM）
- 情况： 官方仓库只有 Nginx 1.22，但你需要在生产前先测试最新的 Nginx 1.25 测试版以评估新 HTTP/3 功能，并添加一个尚未提供 RPM 的第三方认证模块。
- 步骤 (源码)：
  1. 从 Nginx 官网下载 nginx-1.25.1.tar.gz。
  2. dnf install gcc make pcre-devel openssl-devel zlib-devel (解决核心编译依赖)。
  3. 下载第三方模块源码。
  4. 配置：./configure --prefix=/opt/nginx-1.25.1 --with-http_v3_module ... --add-module=/path/to/thirdparty_module。
  5. make -> sudo make install。安装到 /opt/ 而非 /usr/local/ 进行更严格隔离。设置 $PATH (/opt/nginx-1.25.1/sbin) 或服务文件指向此目录。
  6. 详细记录所有步骤和依赖。密切关注上游安全公告，规划手动更新。
- 替代方案 (推荐：自定义 RPM)：
  1. 下载 Nginx 官方的 SRPM 包或从仓库获取 BaseOS 的 SRPM (dnf download --source nginx)。
  2. 安装构建依赖 (sudo dnf builddep nginx-X.Y.Z.src.rpm).
  3. 修改 .spec 文件：升级版本号为 1.25.1（或下载新 nginx.spec），添加第三方模块的 --add-module 配置选项。
  4. 使用 rpmbuild 重新构建 RPM。
  5. 安装生成的自定义 RPM。这样定制版也可通过 dnf 管理。

8. 结论#

在 RPM 驱动的 Linux 世界中，RPM 包应该是你默认且优先选择的软件安装方式。它为生产环境的稳定性、安全性、可维护性和管理效率树立了标杆。只有在 RPM 无法满足你对软件特定版本、深度功能定制或极致性能优化的明确且必要需求时，才应考虑更具挑战性的源码编译安装路径。

选择源码安装务必谨慎评估维护负担和安全风险，并严格遵守最佳实践：

优先使用包管理器安装开发依赖 (*-devel)。
将软件安装到隔离位置（如 /usr/local, /opt, 用户目录）。
做好详尽的安装步骤记录。
强烈考虑在容器内编译以保护宿主机系统并简化部署。
主动负责后续的安全更新工作。

理解两种方式的本质区别、适用场景和各自的工具箱，将使你能够更自信、更高效地在 Linux 系统上部署和维护所需软件。让 RPM 的自动化便利服务于你的日常需求，让源码包的强大灵活性服务于你的特殊挑战。

9. 参考资源#

RPM 官方文档：
- RPM Project Homepage: https://rpm.org/
- RPM Packaging Guide: https://rpm-packaging-guide.github.io/ (Excellent resource for RPM specifics)
主流发行版文档：
- Red Hat Enterprise Linux Documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux
- Fedora Project Wiki (Packaging, DNF): https://fedoraproject.org/wiki/
- openSUSE Documentation (YaST, rpm): https://doc.opensuse.org/
依赖与包查询：
- RPMDB Search Engine (Fedora, RHEL, CentOS): https://rpmfind.net/
- Fedora Packages: https://src.fedoraproject.org/
- EPEL Packages: https://docs.fedoraproject.org/en-US/epel/
编译工具链：
- GNU Autoconf: https://www.gnu.org/software/autoconf/
- CMake: https://cmake.org/documentation/
- GNU Make: https://www.gnu.org/software/make/manual/
源码包示例：
- Official Nginx Source Download: https://nginx.org/en/download.html
- GNU Project FTP Site: https://ftp.gnu.org/gnu/
打包：
- Fedora Packaging Guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/
- CentOS / RHEL SRPMs: (Typically accessed via the distribution's SRPM repository).
容器化:
- Docker Documentation: https://docs.docker.com/
- Podman Documentation: https://docs.podman.io/
版本管理器:
- pyenv: https://github.com/pyenv/pyenv
- nvm: https://github.com/nvm-sh/nvm