如何解决RPM包缺失问题_yum/dnf本地源配置与依赖补齐-Oracle-PHP中文网

rpm包缺失时，根本原因在于本地源未覆盖所有依赖层级，yum localinstall仅解决显式依赖，不处理传递依赖；需用createrepo构建本地源并启用对应仓库。

rpm包缺失时，直接用 yum localinstall 或 dnf install --allowerasing *.rpm 往往不能真正解决问题——根源不在安装命令，而在本地源未覆盖构建/运行所需的所有依赖层级。

为什么 `yum localinstall` 仍会报“xxx is not installed”？

因为 yum localinstall 只解决“已下载 RPM 包的显式依赖”，但不自动拉取这些依赖的依赖（即 transitive dependencies）。尤其当你的 RPM 是从非标准渠道编译（如自建 SPEC、mock 构建）而来时，Requires 字段可能指向仓库里不存在的包名（比如 libgrass_rli.so()(64bit)），或依赖版本与当前系统仓库不匹配。

典型错误：error: package grass-6.4.4-1.el6.x86_64 requires libgrass_rli.so()(64bit) —— 这个 so 不在 base 仓库，而是在 EPEL 或第三方 repo
真实场景：你拿到一个别人编译好的 myapp-1.2-1.fc38.x86_64.rpm，在干净的 CentOS Stream 9 上执行 yum localinstall，结果卡在 python3.11dist(pydantic)
根本原因：本地没启用对应源，或源里没同步该包的元数据（repodata 缺失/过期）

快速补全本地源：三步生成可工作的 `file://` 源

不用改 /etc/yum.repos.d/，也不用搭 HTTP 服务，直接用 createrepo 在本地目录建一个最小可用源。

把所有要装的 RPM（含你自己的 + 从其他机器 yumdownloader --resolve 拉来的依赖）统一放进 /tmp/myrepo/
运行：createrepo -v /tmp/myrepo/ —— 它会生成 repodata/ 目录，这是 yum/dnf 能识别的关键

创建 repo 文件：/etc/yum.repos.d/local.repo，内容只写三行：

[local]
name=Local RPMs
baseurl=file:///tmp/myrepo/
enabled=1
gpgcheck=0

刷新缓存：dnf makecache，再试 dnf install myapp-1.2-1.fc38.x86_64.rpm，依赖就能自动解析了

`yumdownloader --resolve` 和 `dnf download --alldeps` 的关键区别

两者都用来批量下载依赖，但行为差异直接影响你能否一次配齐：

yumdownloader --resolve（RHEL/CentOS 7/8）：只下载当前系统已启用仓库中的依赖，不会跨架构（比如不拉 aarch64 包到 x86_64 主机），且对 BuildRequires 无感知
dnf download --alldeps（Fedora/RHEL 9+）：默认启用 --source 以外的所有 repo，支持 --archlist 指定目标架构，更可靠；但若 RPM 的 Requires 写的是虚拟提供（如 python3dist(requests)），仍需确保对应 python3-requests 包已存在于启用的源中
实操建议：先用 rpm -qpR myapp.rpm 看清所有 Requires，再对照 dnf repoquery --whatprovides "python3dist(requests)" 验证是否能命中 —— 别等安装时报错才回头查

别跳过 mock：干净环境才是依赖问题的照妖镜

你在本机 yum install 成功，不代表 RPM 包真的“自带完整依赖”。很多包靠本机已装的开发库、头文件、甚至 /usr/local/bin 下的手动编译工具链“侥幸通过”，一换机器就崩。

用 mock -r epel-9-x86_64 --rebuild myapp.src.rpm 构建一次，mock 会严格按 SPEC 中的 BuildRequires 初始化 chroot，任何漏写的依赖都会立刻暴露为 configure/make 错误
构建成功后，进入 mock 根目录：/var/lib/mock/epel-9-x86_64/root/，运行 rpm -qa | sort > pkg-list.txt —— 这份清单就是你最终部署时必须保证存在的最小包集合
最容易被忽略的一点：mock 默认不包含 epel-release，如果你的 SPEC 依赖 EPEL 包，得先 mock -r epel-9-x86_64 --init && mock -r epel-9-x86_64 --install epel-release，再 rebuild

依赖问题从来不是“少装一个包”的事，而是“声明是否完整 + 源是否可达 + 环境是否隔离”的三角验证。mock 里跑不过的包，就算你用 --nodeps 强装进生产机，迟早会在某个 systemctl reload 时静默失败。