假设
老实说，我对 snap-packages 了解不多——但这与这个问题无关——见下文。我认为该系统与现有系统有很大不同。
这种改变有意义吗？
是否有足够强烈的实际需求？也就是说，是否有足够重要的新用例来开发新格式以及相关基础设施？
改变当前方法以涵盖新用例是否不可行？
还是我没抓住重点？
我看到的可能主要是营销手段——新名称和新展示，但技术变化极小，以便让任何人都认为它是“新的和更好的”，并且可能真的被使用。此外，新软件包可能与现有格式非常接近，因此主要只是对用户的展示方式发生了变化。当然，这可能是一个好的解决方案。在这种情况下，这个问题就没那么重要了。
然后，我希望这仍然足够有用，可以回答一些侧面问题。如果问题对新用户没有帮助或造成混淆，请告诉我，我很乐意将其删除。
那么，它们为什么存在呢？
背景
我的第一反应是“这毫无意义！”
这类似于物理网站上有人不高兴地问为什么没有人在答案中讨论他的绝妙新想法。这看起来很像是荒唐的想法；与实际的物理知识相差甚远，甚至很难找到一个切入点。我写了一个答案，没有用一个字来触及他的想法，但解释了为什么人们不会讨论假设的荒唐想法——这不是第一次发生这种情况。我认为答案实际上切中要害。
如果我的假设正确，这个案例也是类似的。
但也可能不是——让我们看看。
答案1
是的，确实有需要。
自从一个软件第一次依赖于另一个软件以来，就确实需要这样的东西。
让我们明确一点：
管理依赖关系是难的。
它的名字是有原因的依赖地狱。RPM 和 Debian 等打包系统的设计初衷就是避免依赖地狱。然而，有人必须付出代价：
- 在 Windows 上，程序会捆绑依赖项，因此用户必须负责升级（以及由此导致的任何安全问题）。如果我（开发人员）想要某个应用程序的某个版本 X，那么很简单：我会随应用程序一起提供它。现在我该如何处理更新？
- 在大多数 Linux 发行版（Debian 或 Red Hat 之后）中，程序可以依赖于存储库中的软件，存储库中的程序必须依赖存储库中的软件。如果我想要某个应用程序的某个版本的 X，并且发行版提供了 X，那么很简单：我依赖它。如果发行版没有提供呢？那么：???
- 在发行版中添加多个版本会增加维护人员的负担
- 失去使用依赖项选择版本的能力会增加开发人员的负担
- 无法使用所选应用程序版本会让用户感到沮丧
无论采用哪种方法，都会造成相当大的自由丧失。
这就是 snap 的作用所在：它们让开发人员包含版本 X，并让打包系统管理更新。谁来支付费用？用户：
- 需要更多空间。
- 由于粗心的开发人员在修补依赖项时没有重建他们的快照，从而使他们面临风险。
作为交换我能得到什么好处？
- 除了通过更新实现的安全性（坦率地说，没有多少人关心这一点），用户不必担心 snap 的依赖性。这个词基本上失去了意义。
- 除了安全更新之外，软件开发人员不需要担心让用户安装正确的依赖项。
答案2
snap 的一个特别有用的功能是能够为开发人员选择一个提供多个渠道的渠道，例如发布，候选人，掌握， ETC。
例如，点击渠道按钮nextcloud将显示如下屏幕截图中的对话框。
其他强大的卖点是隔离性、不变性和沙盒，它们由安全策略上下文，允许定义每个应用程序的权限，也称为“插件”，例如：
- 读/写位置
- 访问可移动存储
- snap 被列入白名单/黑名单的国家
- 网络访问
- 照相机、打印机、操纵杆、GPS 定位
- 系统设置
- ...Snap 接口的完整列表
该方法在某种程度上模仿了 MacOS 应用程序捆绑和 Android 的应用程序沙盒，具有权限和内容提供商/接收器。
现在，想象一下您需要运行十几个应用程序，每个应用程序都有自己版本的某些库、自己版本的 Python/Ruby/NodeJS 运行时，并且您不想陷入依赖地狱并弄乱或污染您的系统库、系统 Python/Node/Perl/Ruby 模块等。
实际用例
在 raspberry pi 4 上，存储库中可用的 PHP 最新版本是 7.3，如果您碰巧需要运行需要更高版本（例如较新版本的
nextcloud）的程序，那么您必须找到一种绕过 ootb 包管理器的方法，而这反过来可能会破坏其他包或导致不稳定。以 snap 形式运行 nextcloud 可让您运行所需的版本，无论您通过系统包管理器默认安装了哪些依赖项。此外，snap 具有自动更新的选项，这也很方便。您需要同时运行同一个 Web 服务器的不同版本，例如 apache2、nginx 或 caddy，因为您有多个应用程序，每个应用程序都需要特定的版本。