我是在多个 Linux 打包发行版中分发的 C++ 库的作者。该库包括标题和源代码；Linux 软件包将其分发为头文件 + 共享库 (.so)。
我正在寻找可以使 Linux 软件包维护者的生活更轻松的指南。
我感兴趣的事情包括：
API 兼容性（例如更改函数签名）。显然，保持跨次要版本的兼容性至关重要。主要版本变化如何？
二进制兼容性（例如改变外部可见数据结构的大小）。在次要版本中与 ABI 兼容有多重要？在主要版本中打破它有什么问题吗？
构建版本控制建议。我目前正在使用 CMake - 我应该设置任何特定设置以最大限度地提高包维护人员可以使用我的 CMakeLists.txt 的机会？
如果还有什么我想念的，我也很高兴听到。
让我来解决 ABI 部分。这在很大程度上取决于您是否会提供可以在任何地方工作的预构建二进制文件，或者您是否依赖分销商为您构建它。
考虑 Debian：一旦软件包在 Debian 中，构建主机会在每个支持的平台上重新编译每个更新。C ABI 很少更改，但 C++ ABI 需要特别注意（如 2005 年发给 debian 开发人员的消息中所述：http: //lwn.net/Articles/139810/）
我认为提供一个在任何地方都可以使用的 C++ 包是不合理的。ABI 太特定于站点：https ://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
作为 Linux 维护者，我可以说您的库的向后二进制 (ABI) 和源 (API) 兼容性对我们来说非常重要。
API 更改可能会破坏依赖于您的库的发行版中某些应用程序（或其他库）的重建。这可能会破坏分布的大规模重建。
ABI 更改可能会破坏特定的二进制更新。如果检测到一些危险的更改，我们需要验证更新库中的 ABI 更改并重建所有依赖的应用程序。在这种情况下，用户应该下载库和所有相关应用程序的更新包。如果库是落后的 API 和 ABI 稳定的，那么我们可以只更新库包。
如果您破坏了 ABI，请更改SONAME您的库（bump 版本）。请不要在微/补丁版本中引入 API/ABI 更改。
我建议您使用abi-compliance-checker工具来验证您的库的 API/ABI 向后兼容性。请参阅 Qt 库工具的示例报告：http: //abi-laboratory.pro/tracker/timeline/qt/
您需要使用附加选项编译库的调试版本，并在abi-dumper工具-g -Og的帮助下转储库的 ABI 。然后比较两个不同版本的 ABI 转储以生成 ABI 更改报告。
