假设条件

老实说，我对snap-packages知之甚少-但这与这个问题无关-参见下文。我认为该系统与现有系统明显不同。

更改有意义吗？

有没有足够的实际需求？那就是-是否有一个新的用例，它对开发新格式足够重要-以及相关的基础架构？

改变当前方法来覆盖新的用例也是不可行的吗？

还是我错过了重点？

我所看到的可能主要是市场营销-最小化技术更改的新名称和名称，从而有机会让任何机构认为它是“新的更好的”并且可以实际使用。同样，可能新包装太紧密地基于现有格式，以至于大多数情况下是向用户的展示方式的变化。当然，那可能是一个很好的解决方案。在这种情况下，这个问题没有太大的意义。

然后，我希望它仍然足以回答各个方面。如果问题对您没有帮助或对新用户造成困扰，请告诉我，我们很乐意将其删除。

那么，为什么它们存在呢？

背景

我的第一个反应是“那没有道理！”

这类似于在物理站点上有人不高兴地问，为什么没人在回答中讨论他的出色新想法的情况。它看起来很像crackpot的想法；与实际的物理知识相距甚远，甚至很难找到起点。我写的答案没有一个字就能触及他的想法，而是解释了为什么人们不会讨论假设的骗子想法-而不是第一个例子。我认为答案实际上是正确的。

如果我的假设是正确的，这种情况是相似的。

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

是的，确实有需要。

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

让我们澄清一下：

管理依赖关系很困难。

将其称为依赖地狱是有原因的。创建诸如RPM和Debian的打包系统的目的是避免依赖地狱。但是，必须由他人来支付费用：

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

两种方法都大大降低了自由度。

这就是快照的来源：它们让开发人员包括X版本，并让打包系统管理更新。谁支付费用？用户：

• 需要更多空间。
• 通过修补粗心大意的开发人员将它们置于风险之中，从而在修补依赖项时不重建快照。

作为交换，我可以获得什么好处？

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

快照的一个特殊功能可能有用，它是为提供多个渠道的开发人员选择渠道的能力，例如release，候选人，master等。

例如，单击的“ 通道”按钮nextcloud将在下面的屏幕快照中显示对话框。

其他的强项是隔离，不变性和沙箱，它们由安全策略上下文控制，允许定义每个应用程序的权限，例如，也称为“插件”：

• 读/写位置
• 访问可移动存储
• 快照被列入白名单/黑名单的国家
• 网络访问
• 相机，打印机，操纵杆，GPS位置
• 系统设置
• ...快照接口的完整列表

该方法在某种程度上模仿了MacOS应用程序捆绑包和具有权限和内容提供者/接收者的Android应用程序沙箱。

现在，假设您需要使用自己的某些库版本，自己的Python / Ruby / NodeJS运行时版本运行许多应用程序，而又不想遇到依赖地狱并弄乱或污染系统库，您的系统Python / Node / Perl / Ruby模块等。