Debian和Fedora试图解决依赖问题

Linux发行版面临依赖性增加的问题 的项目，虽然 保留Python，Perl和Ruby代码的依赖项数量 在合理的范围内，JavaScript项目会尝试分成非常小的库，通常执行简单的功能。

NPM存储库已经拥有超过一百万个软件包 和典型应用 链接到数百个依赖项，而后者又具有各自的依赖性，这使得很难在Linux发行版上维护和分发带有JavaScript应用程序的传统软件包。

由于JavaScript库依赖关系相互纠缠在一起，因此在发行版中使用此类库更新任何软件包 它可能会破坏其他程序包。

版本绑定加剧了这个问题：一个库可能需要一个版本的依赖关系才能稳定运行，而另一个库可能需要另一个版本。

许多项目需要使用最新版本的库才能工作， 并不总是满足发行版的稳定性要求（在Node.js生态系统中使用最新版本的框架进行持续开发，并且发行版需要几年的支持）。

尝试仅在发行版中修复软件包版本 导致过时版本的增加 在存储库中已经多年没有更新了。 一个包装的维护中断会对许多其他包装产生不利影响，并带来更多问题。

此外，l交叉依赖 导致以下事实： 无法从系统中卸载Node.js从而阻止您卸载其他Node.js程序。

为了解决这个问题，Fedora项目最近批准了一项计划，该计划将停止使用基于Node.js的项目中的库来默认形成单独的软件包。

他决定从Fedora 34开始，仅为Node.js提供基本的程序包，包括解释器，标头，主库，二进制文件和基本的程序包管理工具（NPM，yarn）。

在使用Node.js的Fedora存储库应用程序中， 允许将所有现有的依赖项嵌入到程序包中，而无需划分和分隔单独程序包中使用的库。

嵌入库将消除小程序包的混乱情况，简化程序包维护（以前，维护人员使用程序库检查和测试数百个程序包所花费的时间比使用程序的主程序包要花费更多的时间），使基础结构免于冲突库并解决与库版本链接的问题（维护程序将在软件包中包括经过测试和生产测试的版本）。

整合的弊端将是进行更正过程的复杂化 到库中的漏洞，这需要包括漏洞库在内的所有软件包的维护者进行协调工作。 程序包可能会忘记更新易受攻击的内置库，并且程序包将不被注意的危险。

的开发者 Debian也正在讨论切换到类似的软件包依赖集成模型。 除了Node.js之外，讨论还涉及使用PHP和Go语言为Kubernetes平台和项目创建软件包的趋势，为此，它们倾向于划分为较小的依赖项。 尚未做出任何决定，但希望随着时间的流逝，问题只会变得更加严重，并且该项目迟早会被迫采取行动。

列举了gvm（Greenbone漏洞管理）安全扫描程序的gsa（Greenbone安全助手）Web界面，作为软件包维护者所遇到问题的一个示例。

事实证明，Desa发行的gsa版本与gvm的较新版本不兼容，但由于将gsa包含重大更改并使用npm下载必需的Node.js库，因此无法将gsa更新到当前版本。

请求的库太多了，需要有人在Debian中创建新的软件包来维护它们，因为Debian规则禁止在构建过程中加载外部组件。

数据来源： https://lwn.net/