Linux yum安装软件依赖报错解决方法

先说几个核心判断：yum 安装软件时遇到依赖报错，绝大多数情况下不是你输错了命令，而是源、缓存或锁文件这三个环节出了问题。理顺这些，大部分“No package”和“冲突”都能迎刃而解。

No package xxx available：先确认源是否正常运作

这个报错直白得有点让人抓狂——说白了就是 yum 根本没找到那个包。为什么？不是你写错包名，而是源里压根没有它。

第一时间运行 yum repolist，查看当前有哪些仓库已被启用。如果输出中没有 base、updates 或你所需的 epel，那么根源就清楚了：源要么未开启，要么配置已经失效。

几个典型陷阱需要留意：

• CentOS 7 必须依赖 base 和 updates，默认路径指向 http://mirror.centos.org/centos/7/...。但 CentOS 7 已停止更新，所以必须手动更换为国内镜像，例如阿里云或清华源，然后更新 /etc/yum.repos.d/CentOS-Base.repo。
• EPEL 源的版本必须与系统大版本严格一致。CentOS 7 就安装 epel-release-7，误装 epel-release-8 不仅会立即报依赖错，还会连累后续所有安装操作。
• 第三方源如 remi、ius，需要检查对应模块是否已显式启用。举个例子，remi-php74 必须手动执行 yum-config-manager --enable remi-php74 才能生效。

ERROR: XZ COMPRESSION NOT AVAILABLE：缓存损坏，别犹豫直接删

这个错误看着吓人，本质上并非缺失依赖，而是 yum 读取元数据时连 .xz 这类压缩格式都无法识别。原因通常是底层 liblzma 或相关插件被破坏、版本不兼容，多见于强制卸载或混装 epel 之后。

修复这个环境所需的精力远不如直接清除残留缓存来得快。操作顺序很重要：

1. 先卸载 epel：yum remove epel-release（如果之前安装过的话）
2. 直接删除对应缓存目录：rm -rf /var/cache/yum/x86_64/7/epel/（路径中的 7 务必替换成你的系统版本）
3. 然后执行 yum clean all，再 yum makecache

注意，不要跳过 rm -rf 这一步。很多时候 yum clean all 无法彻底清除损坏的 xz 元数据索引，手动删除才是真正的解决办法。

依赖冲突或版本不满足：借助工具找出真正的瓶颈

当 yum 提示 package A requires B >= 2.0, but B-1.9 is installed 时，千万别直接使用 --skip-broken。这种做法只是掩耳盗铃。

yum 默认只走“安全升级”路线，但冲突的源头往往隐藏在 Obsoletes 或模块流切换这些不易察觉的地方。正确的做法是：

• 使用 yum deplist xxx 查看真实依赖链，重点关注 provider: 行，确认哪个 repo 提供你所需的版本。
• 模拟一次安装过程：yum install xxx --assumeno --debugsolver，输出中会明确标出第一个卡点——例如某个包被 obsoleted by yyy-3.0。
• 不想太激进的话，可以临时放宽策略：yum install xxx --setopt=strict=0，让 yum 尝试降级或替换，而不是直接拒绝。

这里有个容易被忽视的细节：CentOS 7 默认使用 yum 3.x，根本不支持 dnf module。如果误启用了模块化仓库，反而会触发不可逆的依赖断裂，到时候连 rollback 都救不回来。

Permission denied 或 lock 被占：别急着 kill -9

Another app is currently holding the yum lock 这个提示，不一定真的意味着另一个 yum 还在运行。很多时候是上次异常退出后留下的 /var/run/yum.pid 或 /var/lib/rpm/.rpm.lock 没被清理掉。

处理顺序很关键：

1. 先确认进程是否存在：ps aux | grep -E 'yum|dnf'，真有进程再 kill。
2. 删除 pid 文件：rm -f /var/run/yum.pid
3. 更要紧的是 rpm 层的锁文件：rm -f /var/lib/rpm/.rpm.lock。这一步容易被忽略，但即使 yum 解锁了，rpm 层拒绝写入的话，一切操作还是卡住。
4. 如果怀疑 rpm 数据库已损坏，可以补一记 rpm --rebuilddb，不过这个操作耗时较长，只在必要时使用。

很多人遇到“依赖错”时绕了一大圈，最后发现其实是 rpm 数据库卡在了中间状态。表现就是依赖检查结果混乱，此时清缓存无效，必须重建 rpm 数据库或至少释放锁文件。