为什么会存在 snap-packages - 真的有必要吗？

Question

假设

老实说，我对 snap-packages 了解不多——但这与这个问题无关——见下文。我认为该系统与现有系统有很大不同。

改变有意义吗？

是否有实际需要，足够强大？也就是说 - 是否有一个新的用例，它足够重要以开发一种新的格式 - 以及相关的基础设施？

更改当前方法以涵盖新用例是否不可行？

还是我错过了重点？

我所看到的可能主要是营销 - 新名称和用于最小技术更改的介绍，以便有机会任何机构将其视为“新的和更好的”并且它可能会被实际使用。此外，新的软件包可能与现有格式非常接近，以至于它主要是对用户呈现方式的改变。当然，这可能是一个很好的解决方案。在这种情况下，这个问题就没有多大意义了。

然后，我希望这仍然足以回答侧面问题。如果问题对新用户没有帮助或混淆，请告诉我，我很乐意将其删除。

那么，它们为什么存在？

---

背景

我的第一反应是“这没有意义！”

这类似于在物理站点上，有人不高兴地问，为什么没有人在答案中讨论他出色的新想法的情况。它看起来很像疯子的想法；与实际的物理知识相去甚远，以至于很难找到一个起点。我写了一个没有用一个词触及他的想法的答案，但解释了为什么人们不会讨论假设疯狂的想法 - 不是第一个案例。我认为，答案实际上是切中要害。

如果我的假设是正确的，那么这个案例是类似的。

但是，也许不是 - 让我们看看。

Answer 1

是的，确实有需求。

自从一个软件第一次依赖另一个软件以来，就真的需要这样的东西。

让我们说清楚：

管理依赖项很困难。

它被称为依赖地狱是有原因的。像 RPM 和 Debian 这样的打包系统是为了避免依赖地狱而创建的。但是，必须有人支付费用：

1. 在 Windows 上，程序捆绑了它们的依赖项，用户必须处理升级（以及由于缺少升级而导致的任何安全问题）。如果我的开发人员想要我的应用程序的 X 版本，很简单：我将它与我的应用程序一起提供。现在我如何处理更新？
2. 在大多数 Linux 发行版（继 Debian 或 Red Hat 之后）中，程序可以依赖于存储库中的软件，存储库中的程序必须依赖于存储库中的软件。如果我想要我的应用程序的版本 X，并且发行版提供 X，很简单：我依赖它。如果发行版没有？然后： ？？？
   • 向发行版添加多个版本会增加维护者的负担
   • 失去使用依赖项选择版本的能力增加了开发人员的负担
   • 失去使用所选应用程序版本的能力使用户感到沮丧

这两种方法都有相当大的自由度损失。

这就是 snap 的用武之地：它们让开发人员包含版本 X，并让打包系统管理更新。谁支付费用？用户：

• 由于需要更多空间。
• 由于粗心的开发人员在修补依赖项时没有重建它们的快照，从而使它们处于危险之中。

作为交换，我得到了什么好处？

• 除了通过更新提供的安全性（坦率地说，没有足够的人关心），我用户不必担心与 snaps 的依赖关系。这个词大多失去意义。
• 除了安全更新之外，软件开发人员无需担心让用户安装正确的依赖项。