6.2.捆绑库

本节解释了为什么捆绑的依赖被认为是坏的，以及如何处理它们。

6.2.1. 为什么捆绑式图书馆是坏的

有些软件需要搬运工找到第三方库， 并将所需的依赖关系加入到移植中。另一些软件则将所有必要的库捆绑在发行文件中。第二种方法起初看起来比较容易，但也有一些严重的缺点：

这个列表松散地基于 Fedora 和 Gentoo 的维基，两者都在 CC-BY-SA 3.0 许可下授权。

安全问题

如果在上游库中发现了漏洞并在那里进行了修正， 它们可能不会在与 port 捆绑的库中得到修正。一个原因可能是作者没有意识到这个问题。这意味着， 移植者必须修复它们， 或升级到没有漏洞的版本， 并将补丁发送给作者。这一切都需要时间，这导致软件的脆弱时间超过了必要的时间。这反过来又使得在没有不必要地泄露漏洞信息的情况下协调修复工作变得更加困难。

Bug

这个问题与上一段中的安全问题类似，但一般不那么严重。

岔路口

一旦捆绑了上游库，作者就更容易分叉。虽然乍一看很方便，但这意味着代码与上游的分歧，使得解决软件的安全或其他问题变得更加困难。一个原因是，打补丁变得更难。

分叉的另一个问题是，由于代码与上游不同，错误会被反复解决，而不是在一个中心位置解决一次。这就违背了开放源码软件的初衷。

符号碰撞

当一个库被安装在系统上时，它可能会与捆绑的版本发生冲突。这可能会在编译或链接时造成直接错误。它也可能在运行程序时引起错误，这可能更难追踪。后一个问题可能是由于两个库的版本不兼容造成的。

许可证制度

当捆绑来自不同来源的项目时，许可证问题可能更容易出现，特别是当许可证不兼容时。

浪费资源

捆绑的库在几个层面上浪费资源。构建实际的应用程序需要更长的时间，特别是当这些库已经存在于系统中时。在运行时，当一个程序已经加载了全系统的库，而捆绑的库又被另一个程序加载时，它们会占用不必要的内存。

浪费精力

当一个库需要为 FreeBSD 打补丁时，这些补丁必须在捆绑的库中再次复制。这就浪费了开发者的时间，因为这些补丁可能无法干净地应用。也很难注意到这些补丁首先是需要的。

6.2.2. 如何处理捆绑的图书馆

在可能的情况下， 通过在 port 中加入 LIB_DEPENDS 来使用非捆绑版本的库。如果这样的 port 还不存在， 请考虑创建它。

只有在上游有良好的安全记录的情况下才使用捆绑的库，使用非捆绑的版本会导致过于复杂的补丁。

注意

在一些非常特殊的情况下， 例如仿真器， 如Wine， 一个 port 必须捆绑库， 因为它们采用了不同的架构， 或者为了适应软件的使用而进行了修改。在这种情况下， 这些库不应该暴露给其他 port 来进行连接。在 port 的 Makefile 中加入 BUNDLE_LIBS=yes。这将告诉 pkg(8) 不要计算所提供的库。在向 port 添加这个内容之前， 请务必询问 Ports Management Team [e-mail]。