DNF/YUM安装java-1.8.0-openjdk-headless时为何自动安装旧版nss？

问题背景 #

包java-1.8.0-openjdk-headless-1:1.8.0.352.b08-2.el8_7依赖nss，原本通过repoquery验证支持任意版本，且系统中存在更新的nss版本（最高为3.79.0-10.el8_6）：

# dnf list --showduplicates nss
nss.x86_64    3.41.0-5.el8
...
nss.x86_64    3.79.0-10.el8_6

但安装该Java包时，却自动安装了旧版本nss-3.44.0-15.el8：

# dnf install java-1.8.0-openjdk-headless-1:1.8.0.352.b08-2.el8_7.x86_64
Installing:
 java-1.8.0-openjdk-headless  x86_64   1:1.8.0.352.b08-2.el8_7
Installing dependencies:
 ...
 nss   3.44.0-15.el8
 nss-softokn   3.79.0-10.el8_6 
 nss-softokn-freebl   3.79.0-10.el8_6
 nss-sysinit  3.44.0-15.el8
 nss-util  3.79.0-10.el8_6

该问题数月前开始出现，此前安装会自动选择最新版本的nss。

已完成的排查 #

• 单独安装该Java包的所有依赖，未发现任何依赖明确要求nss版本为3.44.0-15.el8；
• 单独安装nss时，默认会下载最新版本；
• 使用--best选项安装Java包，结果依旧选择旧版nss；
• 用dnf repoquery --requires --resolve查询该Java包，显示其依赖nss-0:3.79.0-10.el8_6.x86_64：

  $ dnf repoquery --requires --resolve java-1.8.0-openjdk-headless-1:1.8.0.352.b08-2.el8_7.x86_64
  ...
  nss-0:3.79.0-10.el8_6.x86_64
  

可能原因及解决方向 #

1. 依赖链隐性冲突 #

从安装日志看，nss-softokn、nss-util等组件安装的是3.79.0-10.el8_6，而nss-3.44.0-15.el8可能是当前唯一能和这些组件版本兼容的nss版本。DNF的依赖 resolver 为了满足整体依赖兼容性，自动选择了旧版nss。

验证方法：尝试手动安装最新版nss+Java包，查看是否触发冲突提示：

dnf install java-1.8.0-openjdk-headless-1:1.8.0.352.b08-2.el8_7.x86_64 nss-3.79.0-10.el8_6.x86_64

若出现冲突信息，可明确是哪个组件导致的版本绑定。

2. 仓库元数据异常 #

仓库元数据未及时同步或优先级设置异常，可能导致DNF认为nss-3.44.0-15.el8是更合适的版本。

解决方法：刷新仓库元数据后重试安装：

dnf clean all && dnf makecache
dnf install java-1.8.0-openjdk-headless-1:1.8.0.352.b08-2.el8_7.x86_64

3. 强制指定版本安装 #

若确认最新版nss与Java包兼容，可强制指定版本安装：

dnf install java-1.8.0-openjdk-headless-1:1.8.0.352.b08-2.el8_7.x86_64 nss-3.79.0-10.el8_6

若安装成功，说明是resolver的选择逻辑问题；若失败，则确实存在兼容性约束。

4. 查询完整依赖链 #

使用dnf repoquery --deplist查看Java包的完整依赖树，找出是否有间接依赖限制了nss版本：

dnf repoquery --deplist java-1.8.0-openjdk-headless-1:1.8.0.352.b08-2.el8_7.x86_64 | grep nss

内容的提问来源于stack exchange，提问作者Zucca