Question

有一个我负责分发的图书馆套餐。前段时间，构建系统从我们自制的Makefile切换到使用GNU Autotools。因此，使用libtool，我们现在可以轻松管理多个已安装的库版本。切换到RPM进行分发后，我想知道我怎么能＆＃34;医生＆＃34;规范文件，以避免在升级时完全卸载以前的版本。

例如，在安装了虚拟库项目的1.0.0版后，我有

[afalanga@afalanga4 libtest]$ ls /usr/lib64/libaby*
/usr/lib64/libabyss.a   /usr/lib64/libabyss.so    /usr/lib64/libabyss.so.0.0.0
/usr/lib64/libabyss.la  /usr/lib64/libabyss.so.0

然后，sudo yum localupdate ....之后我有以下内容：

[afalanga@afalanga4 libtest]$ ls /usr/lib64/libaby*
/usr/lib64/libabyss.a   /usr/lib64/libabyss.so    /usr/lib64/libabyss.so.0.0.1
/usr/lib64/libabyss.la  /usr/lib64/libabyss.so.0

当然，作为一个libtool制作的图书馆，唯一的＆＃34;真实＆＃34;文件是：libabyss.a, libabyss.la and libabyss.so.0.0.1。在spec文件中应该做些什么来确保在libabyss.so.0.0.0安装后libabyss.so.0.0.1停留？符号链接将相应地处理。

Answer 1

没有真正的方法可以执行您尝试执行的操作，因为用于加载库的符号链接由ldconfig管理，并且基于库的SONAME（请参阅{{ 3}}。所以，即使你保持.so.0.0.1也没有任何东西可以使用它。

如果您希望它们具有兼容性，因为它们可能是不同的ABI，那么您必须确保my post on the topic，但我似乎并不是这样。

除此之外，我不确定RPM是否有任何特殊情况可以在这些情况下保留给定库的多个版本，因为实际上不需要这样做。

Answer 2

嗯，那真的不行。库版本控制的通常GNU构建系统假设是使用described here方案computing为-version-info设置的值。正如迭戈所提到的，即使你能说服RPM留下那些旧的libs（IIRC，我认为你可以在rpm运行时），旧版本与旧版本共享相同的SONAME（例如libabyss.so.0并且在库安装/升级运行ldconfig时基本上是孤立的。

通常当人们想要这样做时，他们会使用libtool -release标志或重命名RPM包，如libabyss0，libabyss1等，以输入SONAME版本号前期。

正确定义用于升级库的spec文件

2 个答案: