Ubuntu soname的Debian包命名策略

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

在soname和包名中应该如何处理这个问题

我想使软件包版本最初为4.0.0。如果我将包命名为libmystuff，那么会出现一个林寻错误，告诉我将包的soname放在包名中（包名与sonames不匹配）。很公平

如果我将程序包命名为libmystuff4，那么我会得到一个名为

libmystuff4-dev_4.0.0-1ubuntu8_amd64.deb的程序包文件，它看起来有点多余，但还行，该程序包适用于主版本4，软件版本为4.0.0。但我还是听到了林寻的一个错误说

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

所以这让我很惊讶，为什么林寻要我把索纳姆的三个部分都放在包名中，而不仅仅是第一部分

在任何情况下，因此我将包名更改为libmystuff4.0.0，现在林寻安静了，但我得到了一个名为
libmystuff4.0.0\u 4.0.0-1ubuntu8\u 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，这会让人非常困惑，对吗？
简短的回答是：将当前soname设置为libmystuff.so.0，当您在4.1.0中中断ABI时，将soname设置为libmystuff.so.1。您需要修补buildsystem并在相关位置引入
set\u属性（TARGET mystuff property SOVERSION 0）

您的SONAME与库的版本不同，可能需要独立发展

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

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

因此，
SONAME
就诞生了。链接到库的任何动态对象都将此字符串嵌入其中，并告诉动态链接器要加载哪个库文件来解析符号

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

这就是林寻警告的来源——没有“奏鸣曲的第一部分”；您的SONAME是字符串
libmystuff.so.4.0.0
。4.0.0部分对人类有意义，而不是链接器

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

这完全独立于库版本——例如，glibc项目目前的版本是2.24，它生成了一个带有SONAME
libc.so.6的库（现在已经完成了20多年）

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