soname 的 Debian 软件包命名策略

Question

我正在为一个库制作一个 Debian 包，我称之为 libmystuff。它目前是 4.0.0 版本，下一个版本将是 4.1.0，并且可能会破坏 API 兼容性。该项目使用 CMake 构建。

在soname和包名中应该如何处理？

我想将软件包版本最初设为 4.0.0。如果我将包命名为 libmystuff，则会收到一个 lintian 错误，告诉我将包的 soname 放在包名称中 (package-name-doesnt-match-sonames)。很公平。

如果我将包命名为 libmystuff4，那么我会得到一个名为 libmystuff4-dev_4.0.0-1ubuntu8_amd64.deb 的包文件，这似乎有点多余，但没关系，该包适用于主要版本 4，软件版本为 4.0.0。但我仍然收到一个 lintian 错误提示，

libmystuff4: package-name-doesnt-match-sonames libmystuff4.0.0

所以这让我很惊讶，为什么 lintian 要我把 soname 的所有 3 部分都放在包名中，而不是只放第一部分？

不管怎样，所以我把包名改成libmystuff4.0.0，现在lintian就安静了，但是我得到一个包文件叫libmystuff4.0.0_4.0.0-1ubuntu8_amd64.deb，看起来超级多余！

我该怎么办？

我在想，即使库版本是 4.0.0，soname 也应该为 0，我应该在他们发布 4.1.0 时将 soname 设置为 1，等等。这需要修补上游 CMake 构建系统，是这是一种可接受的方法吗？虽然在那种情况下 soname 的其他部分呢，我只是将它们设置为 0 吗？那么这个包就是 soname 0.0.0。

否则我必须在他们发布 4.1.0 时将 soname 更改为 5.0.0，这会很混乱，对吧？

Answer 1

简短回答：将当前 SONAME 设置为 libmystuff.so.0，当您在 4.1.0 中破坏 ABI 时，将 SONAME 设置为 libmystuff.so.1。您需要修补构建系统并在相关位置引入set_property(TARGET mystuff PROPERTY SOVERSION 0 )。

您的 SONAME 与您库的版本不同，可能必须独立发展。

更长的答案： 库有点尴尬，因为它们有两个独立的方面可以有效地进行版本控制：source 兼容性和 binary 兼容性。它们分别是 API 和 ABI。库版本可以维护 API 并与源代码兼容，同时破坏 ABI 和二进制不兼容，反之亦然。

幸运的是，需要自动化的唯一部分是运行时二进制兼容性。您可以告诉人们阅读您的文档，说明 API 在 4.0.0 和 4.1.0 版本之间中断；你不能告诉运行时动态链接器去阅读你的文档。

因此SONAME 诞生了。任何链接到你的库的动态对象都嵌入了这个string，它告诉动态链接器要加载哪个库文件来解析符号。

因为它是一个字符串，所以对它基本上没有要求 - 或在其中编码的信息。运行时链接器根本不会解释它；它只关心严格的字符串相等性。

这是 Lintian 警告的来源 - 没有“soname 的第一部分”；您的 SONAME 是 字符串 libmystuff.so.4.0.0。 4.0.0 部分对人类有意义，而不是链接器。

由于 SONAME 本质上是任意的，因此围绕它形成了约定，约定是libmystuff 的第一个版本的 SONAME 应该是libmystuff.so.0，然后 '.0' 应该增加 1每次对 ABI 进行向后不兼容的更改时。所以第一个版本是libmystuff.so.0，第二个ABI是libmystuff.so.1，第三个ABI是libmystuff.so.2等等。

这完全独立于库版本 - 例如，glibc 项目目前的版本为 2.24，并生成一个带有 SONAME libc.so.6 的库（并且已经完成了二十多年）。

如果您使用项目的版本作为 SONAME，那么每次您更改版本时，使用该库的任何内容都必须重新构建才能使用新库。针对 4.0.0 版构建的程序将嵌入 字符串 libmystuff.so.4.0.0，并且不会尝试加载 libmystuff.so.4.0.1。