不同的操作系统有不同的安装包依赖的标准方式；在 OS X 中，所有库依赖项都复制到该App文件夹中。
Windows 应用程序开发人员有两种选择：他们可以将库作为子包安装（例如，游戏安装程序将安装 directX 库）。但通常用户无法选择是否要在系统上复制或共享依赖项
在 Linux 中，包管理器（例如，apt-get）将递归地解析依赖项并在系统范围内安装它们。当然，这并不一定能解决依赖项重复的问题，因为应用程序可能仍然使用同一源库的不同版本或版本
例如，某些应用程序需要libboost-filesystem1.42但该死的，我有 libboost-filesystem-1.49 可用，但这无济于事，因为包解析器无法确定我已经有一个。
另一方面，我不希望在系统范围的路径中安装旧的库，因为我已经有另一个版本了。
问题：是否有或者是否有一个标准的包管理器选项来允许将某些应用程序的依赖项安装在特定于应用程序的文件夹（如AppMac OS X 中的文件夹）中？
答案1
您错了：“旧”库安装在系统范围的路径上，这是理想的行为。它的工作方式是：如果两个库版本在二进制级别兼容，那么您只安装了一个，并且使用该版本的每个应用程序都使用相同的库文件。如果两个库版本在二进制级别不兼容，则您安装了多个副本，每个副本都有自己的名称，并且需要不同版本库的应用程序均使用适当的库文件。
例如，如果您已libboost-filesystem-1.49安装（在/usr/lib/libboost_filesystem.so.1.49.0），则这对需要版本 1.42.0 的应用程序没有帮助，因为二进制文件不兼容。该应用程序需要/usr/lib/libboost_filesystem.so.1.42.0.当您安装应用程序时，包管理器将自动安装所需版本的库。如果您有一个需要 1.42 的应用程序和一个需要 1.49 的应用程序，那么您将在 中拥有两个不同版本的库/usr/lib，每个版本都有自己的文件名，以便它们可以和平共处。如今，大多数包管理器还可以自动卸载任何应用程序不再使用的库版本。
在应用程序目录中安装库是一种处理依赖关系的穷人方式，用于没有良好包管理和分发渠道的操作系统。为了让事情顺利进行，他们将应用程序所需的每个库与应用程序本身捆绑在一起。这意味着您最终会得到同一库版本的多个副本，并且没有简单的方法来升级库 - 您最终会得到同一库的多个过时副本。
没有也不会有在应用程序目录中安装库的选项，因为拥有包管理器意味着您不需要这样做。