Yum 不直接解决冲突，而是通过依赖解析、版本协商和策略干预规避冲突；需先用 yum deplist、--debugsolver 等定位根源，再用 clean、--skip-broken、distro-sync 等缓解，避免混用安装方式及错配仓库。
Yum 本身不直接“解决冲突”，而是通过依赖解析、版本协商和策略干预来规避或绕过冲突。关键在于理解冲突类型，并选用对应命令和参数，而不是强行覆盖。
查清冲突根源再动手
安装失败时，先别急着加参数重试。运行以下命令定位真实瓶颈：
- yum deplist package-name：列出该包所有依赖及其提供者，确认哪个依赖版本不满足
- yum install package-name --assumeno --debugsolver：模拟安装过程，输出中会明确标出第一个无法满足的约束（如 “xxx obsoleted by yyy-2.0”）
- yum repolist enabled：确认 base、updates、epel 等必要仓库已启用，避免因源缺失导致“找不到包”的假性冲突
常用缓解与修复手段
多数冲突可通过以下方式快速缓解，无需手动删包或改配置：
- yum clean all && yum makecache：清除损坏的元数据缓存（尤其 xz 解压失败类错误）
- yum install package-name --skip-broken：跳过引发冲突的包，继续安装其余可解依赖
- yum install package-name --setopt=strict=0：临时关闭严格依赖检查，允许 yum 尝试降级或替换已有包
- yum distro-sync：将系统内所有包对齐到当前仓库最新可用版本，消除因长期未更新导致的版本撕裂
处理已发生的事务中断或残留
强制退出、断电或网络中断后，yum 可能留下未完成事务，后续操作全被阻塞：
- 运行 yum-complete-transaction（需先 yum install yum-utils）尝试续装
- 若失败，用 yum history list 查看最近事务，再执行 yum history redo last 或 yum history rollback last
- 极端情况下，用 package-cleanup --problems 扫描依赖断裂点
避免冲突比修复更重要
很多冲突源于人为操作习惯：
- 不混用 yum install、rpm -ivh 和手动复制二进制——同一软件只走一种安装路径
- 第三方源（如 remi、ius）启用前，先用 yum-config-manager --enable repo-id 显式激活对应模块
- EPEL 版本必须与系统主版本一致（CentOS 7 用 epel-release-7），错装会导致整套依赖链失效
- 生产环境大版本升级前，应构建隔离的私有源，禁用跨版混放 RPM，用 createrepo -g comps.xml 注入语义信息
