我最近了解到，基于 Debian 的发行版本质上有一组固定的公共依赖项和库，任何通过包管理器安装的应用程序都需要使用它们。
与 Windows 相比，我相信每个应用程序通常都会提供自己的依赖项 - 因此 Windows 操作系统安装将多次安装相同依赖项/库的实例，并且每个应用程序都需要管理其依赖项的更新自己的。
我知道一些开发人员开发的软件与 APT 包管理器兼容，但我想一定有很多应用程序开发人员以“Windows”方式创建软件。
所以我的问题是，如果上游开发人员创建他们的软件的目的是分发包含捆绑依赖项的大型整体安装，那么 APT 包维护者是否需要重写源代码，以便软件使用依赖项的公共集合而不是本地依赖项依赖关系？
如果是这样，这种情况是否经常发生？这是包维护人员的主要任务吗？
答案1
所以我的问题是，如果上游开发人员创建他们的软件的目的是分发包含捆绑依赖项的大型整体安装，那么 APT 包维护者是否需要重写源代码，以便软件使用依赖项的公共集合而不是本地依赖项依赖关系？
不一定，只要整体安装不冲突与现有的库或文件名。也就是说，如果系统已经有一个/lib/foobar（版本 12），并且单体包需要并捆绑foobarv.9，则该单体包无法foobar使用 filename 存储其 v.9 /lib/foobar，因为该路径名已被采用 - 但它可以使用/lib/foobar_v9，或者也许.../monolithic_app_dir/lib/foobar。
如果是这样，这种情况是否经常发生？这是包维护人员的主要任务吗？
是的，预防，如果需要的话整理各种级别的依赖地狱是包维护者所做的大部分工作。
答案2
Debian 政策是在创建 debian 软件包时，与程序捆绑在一起的库、工具等应该与其分离。 Debian 政策还要求库至少分成一个运行时包（例如libfoo-version）和一个带有静态库和头文件的开发版本（例如libfoo-version-dev）。
您在自己的系统上做什么是您自己的事，但是任何打包整体应用程序的 Debian 开发人员 (DD) 都应该解绑 - 这意味着要么依赖 Debian 中的现有库，要么为它们创建包（如果它们尚不存在） 。
其他发行版可能有不同的政策，但大多数发行版都要求将官方存储库中的软件包解绑 - 因为捆绑颠覆了打包的意义，并且使得将库安全更新应用于使用特定库的所有程序变得更加困难。