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

Question

我负责分发一个库包。前段时间，构建系统从我们自制的 Makefile 切换到使用 GNU Autotools。因此，使用 libtool，我们现在能够轻松管理库的多个已安装版本。切换到 RPM 进行分发后，我想知道如何 "doctor" 规范文件在升级时避免完全卸载以前的版本。

例如，在安装了一个虚拟库项目的 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 生成的库，唯一的 "real" 个文件是：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（请参阅 my post on the topic。所以即使你保留 .so.0.0.1 也没有人会使用它。

如果您希望它们具有兼容性，因为它们可能是不同的 ABI，那么您必须确保 versioning is done correctly 但从我的阅读来看，情况似乎并非如此。

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

Answer 2

好吧，那真的行不通。通常的 GNU Build System 库版本控制假设是使用方案 described here for computing 您为 -version-info 设置的值。正如 Diego 所暗示的，即使您能够说服 RPM 保留那些旧库（IIRC，我认为当 rpm 为运行时您可以），旧版本与旧版本共享相同的 SONAME（例如 libabyss.so.0) 并且当 ldconfig 在库 install/upgrade.

上是运行时基本上是孤立的

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

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

Proper definition of spec file for upgrading libraries

rpm

autotools

libtool

rpm-spec