我用 aptitude 删除了一些我不再需要的软件包。我很惊讶它们的依赖项都没有被自动删除（因为我认为 aptitude 与 apt-get 不同，默认情况下会这样做），所以我检查了这些依赖项，aptitude why并且所有这些依赖项都标有 status id，根据手册，这意味着“已安装，将被删除”。这什么时候会发生？我试图运行apt-get autoremove，aptitude upgrade，aptititude full-upgrade和apt-get dist-upgrade，和软件包仍然安装。此外，当我运行这些命令时，它们都会打印出0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.什么原因导致0 to remove包与标有状态的包之间存在差异id？
编辑：经过更多的挖掘，我发现所有这些包都被标记为手动安装，即使它们是自动安装的。我查看了我的历史记录，并注意到其中许多是使用 apt-get 而不是 aptitude 安装的，这可能是问题的一部分。我能够使用以下命令将它们全部删除：
# aptitude search "?installed" | grep "^id" | awk '{ print $2 }' | xargs apt-mark auto
# aptitude upgrade
我仍然很好奇“d”状态到底是什么意思，以及 apt-get/aptitude 用它做什么，所以我把这个问题搁置了。
?narrowaptitude 搜索的和选项有什么区别?and？例如，为什么aptitude search "?and(?installed,?origin(backports))"我的系统会返回结果，但aptitude search "?narrow(?installed,?origin(backports))"什么也不返回？
请注意，apt-cache policy在版本返回的包上运行?and表明安装的版本不是来自向后移植的，因此?narrow结果是正确的。但我之前遇到过类似的不直观的结果，?narrow在一些谷歌搜索后已通过使用解决了这些结果，但从未理解为什么。
我在 SE 和其他教程上收到了很多关于此的相互矛盾的信息。大多数人似乎认为so版本是语义版本。然后其他人纠正他们，说它必须符合libtools 约定，并继续隐式假设或暗示传递-version-info C:R:A给 libtools 的数字创建名为 的文件libfoo.so.C.R.A。但我在 libtools 手册中没有看到任何地方明确说明文件的命名方式，这与我所看到的行为不匹配。
我正在构建一个第三方包（gdal），在构建过程中，它调用libtool --mode=link -version-info 25:4:5 <many other arguments>，但是构建后留在 .libs 中的 so 文件具有版本 libgdal.20.5.4。
我尝试了同一库的几个其他版本，它们似乎都遵循相同的模式。当您调用 libtools 时，您传入 current:revision:age，它会生成libfoo.so.current-age.age.revision. 这导致 sonamelibfoo.so.current-age始终是库兼容的最小版本，而不是其他帖子建议的最大版本。
我在 RHEL 7 和 Debian 10 上进行了此测试。
这是事情应该如何进行的吗？这个图书馆在做什么奇怪的事情吗？是否有任何地方可以权威地或至少正确地记录这一点？