首先得明确一个关键点：RPM的依赖检查不是只看库文件名，而是看库的SONAME以及RPM包声明的Provides标记——这也是你改了文件名还是报错的核心原因。

先搞清楚RPM到底在找什么 #

你看到的错误里的libcrypto.so.10(libcrypto.so.10)(64bit)，是RedHat官方openssl-libs包通过RPM的依赖机制声明的虚拟依赖标记，不是单纯的文件名。你可以用这几个命令直观对比差异：

• 查看原openssl-libs包提供的所有依赖标记：

  rpm -q --provides openssl-libs-1.0.2k-8.el7.x86_64
  

• 查看你自己构建的openssl-libs包提供的标记：

  rpm -q --provides openssl-libs-1.1.0g.x86_64
  

• 查看pyOpenSSL的完整依赖：

  rpm -q --requires pyOpenSSL-0.13.1-3.el7.x86_64
  

对比后你会发现，官方包明确提供了libcrypto.so.10(libcrypto.so.10)(64bit)，而你的包只提供了和1.1.0g对应的新标记（比如libcrypto.so.11(libcrypto.so.11)(64bit)），所以RPM认为你的包不满足依赖。

另外，即使你把新库改名为libcrypto.so.10，它的内在SONAME还是libcrypto.so.11（OpenSSL 1.1.x系列的SONAME做了升级），可以用这个命令验证：

objdump -p /usr/lib64/libcrypto.so.10 | grep SONAME

RPM会读取这个SONAME来识别库的版本，所以改文件名根本骗不过它。

解决方法（按稳妥程度排序） #

1. 并行安装新版OpenSSL（最推荐）

不要替换系统自带的openssl，而是把新版安装到独立路径（比如/usr/local/openssl-1.1.0g），这样既不影响系统依赖旧版的工具，又能自己用新版。在spec文件里做这些配置：

• 配置编译参数，指定安装路径：

  ./configure --prefix=/usr/local/openssl-1.1.0g --libdir=/usr/local/openssl-1.1.0g/lib64
  

• 在spec的%install阶段，把库文件安装到指定路径，然后添加%post脚本更新动态链接缓存：

  %post
  echo "/usr/local/openssl-1.1.0g/lib64" >> /etc/ld.so.conf.d/openssl-1.1.0g.conf
  ldconfig
  

• 同时，spec里要避免和系统包的文件冲突，比如不要覆盖/usr/bin/openssl，可以用alternatives工具管理默认版本（可选）。

2. 重新编译pyOpenSSL适配新版OpenSSL

既然你要升级OpenSSL，不如把依赖它的pyOpenSSL也一起升级适配。下载pyOpenSSL的源码，用新版OpenSSL的头文件和库编译：

• 编译时指定新版openssl的路径：

  python setup.py build --openssl-dir=/usr/local/openssl-1.1.0g
  

• 然后把新编译的pyOpenSSL打包成RPM，这样它的依赖就会变成libcrypto.so.11，自然不会再找旧版的依赖。

3. 强制让你的openssl-libs包提供旧版依赖标记（不推荐，风险高）

如果你一定要替换系统openssl，可以在spec文件里手动添加Provides声明，让你的包“假装”提供旧版的依赖：

Provides: libcrypto.so.10(libcrypto.so.10)(64bit)
Provides: libssl.so.10(libssl.so.10)(64bit)

但要注意：OpenSSL 1.1.x和1.0.x的API有不少不兼容的地方，这样做可能会导致系统中依赖旧版openssl的工具（比如ssh、curl等）崩溃，所以除非你完全清楚所有风险，否则不建议这么做。

最后说一下rpm -Va --nofiles --nodigest #

这个命令是用来验证RPM包的文件完整性和一致性的，根本解决不了依赖问题，它的输出只能告诉你哪些文件被修改过，对你当前的问题没有帮助。

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