LWN：Linux Mint拒绝支持Ubuntu的Snap安装包！

关注了就能看到更多这么棒的文章哦～

Linux Mint drops Ubuntu Snap packages

By John Coggeshall
July 8, 2020
原文来自：https://lwn.net/Articles/825005/
主译：DeepL

Linux Mint项目之前威胁说会尽力组织Ubuntu Snap软件包在未经用户同意的情况下通过APT工具安装进来，他们现在已经真的这么做了。Linux Mint对Snap在用户选择和软件自由（software freedom）方面的负面影响表示 "非常担心"。Ubuntu的母公司Canonical似乎愿意寻找一个解决方案来满足Mint这个非常流行的发行版的担忧，但它也有自己的利益需要考虑。

Backstory

Linux Mint发行版以Debian和Ubuntu为基础，提供了这些项目的3万多个软件包。这些软件包的提供使用了这两个发行版中都在使用的著名的APT软件包管理系统。然而，Ubuntu在2014年开始使用一种名为Snap的技术，与APT同时用来发布软件。

Snap是一个自己自足（self-contained）的打包部署系统，旨在能更容易地处理Linux环境中应用程序的依赖关系。Snap是由Canonical所开发，它的设计中就在任意一个软件包里也包含了它运行所需的所有特定依赖文件，全部汇总在一起合并成单一的文件系统映像（image）中。这样一来，可以解决许多软件包安装问题，比如一个软件包在此系统上所以来的库文件版本互相不兼容，那用Snap之后这个软件包就可以正常运行了（因为它内置了所依赖的库文件），甚至可以在一台机器上轻松地共存某一软件的两个不同版本（完全两套依赖文件，版本各不相同）。从本质上讲，它允许每个architecture只要创建一个软件包之后，就可以在任何常见的Linux发行版上运行。

该技术为Canonical和Ubuntu解决了重要的软件包管理问题。它还具有战略性的商业价值，因为它允许Canonical所管理的软件被安装在竞争对手的发行版中。Canonical想要解决的技术问题是希望简化对那些需要在多个Ubuntu版本上正常运行的软件包的开发支持工作，Chromium就是一个例子。如果完全依靠APT的话，就需要为每个Ubuntu发行版维护一个单独的软件包，因为不同的Ubuntu版本都有各不相同且可能互不兼容的库文件版本。这里会有巨大的工作量，是Canonical所不愿意承担的。而Snap就提供了一个优雅的技术解决方案。

从商业角度来看，广泛采用Snap作为通用的软件包分发技术的话，将使Canonical在控制Linux软件分发方面处于有利地位。这一事实并没有被Canonical的竞争对手所忽视。Red Hat也支持类似的Flatpak技术。但与Snap不同的是，Flatpak项目的目标是成为一个独立的社区，是一个 "真正的upstream开源项目，致力于提供所有人都能使用的技术和服务，没有跟特定厂商绑定(true upstream open source project, dedicated to providing technology and services that can be used by all, with no vendor lock-in.)"。

当Ubuntu在Ubuntu 19.10中把Chromium移到Snap发行版时，Linux Mint的问题就凸显出来了。从表面上看，这本身并不是一个问题——Linux Mint项目可以随时提供自己的Chromium APT包。问题的出现，是因为Ubuntu决定在upstream里直接改变Ubuntu chromium-browser APT包。此前，这个APT包会直接安装Chromium而已。改动之后就会先安装Snap包管理工具，然后再安装与Chromium包相应的Snap包，这个过程中完全没有向用户说明发生了什么。

这种行为也不限于Chromium，Canonical也在其他一些软件包上使用了这种方法，比如gnome-software。Linux Mint所不赞同的核心就是这种行为：使用APT安装一个辅助性的、由某家公司所控制的软件包管理系统，之后再安装用户想要的软件。正如Linux Mint博客在Chromium做出上述改动时的评论：

A self-installing Snap Store which overwrites part of our APT package base is a complete NO NO. It's something we have to stop and it could mean the end of Chromium updates and access to the snap store in Linux Mint.

What's at stake and recent events

Linux Mint项目最近的决定并不是关于Chromium，或者某一个软件包而已。而是针对Canonical对Snap和APT采取的整个方法。Snap包实际上是个黑盒子，它们无法独立复制，因为打包的数据完全是由制作者所控制的。此外，Snap包管理器属于Canonical的库中（被称为Snap Store），所以目前也没有独立的第三方Snap包仓库。虽然Snap包可以从其他来源手动下载和安装，但这样做需要在安装时显示指定一个dangerous参数，这个会让用户感觉非常不可靠。

根据Canonical工程经理Ken VanDine的说法，用Snap取代APT包的决定是出于效率的考虑，并把Canonical的精力放到更有价值的事情上去。关于将gnome-software这个APT包移至Snap，VanDine的评论是：

By shipping such a key application as a snap it will continue to keep pressure on to ensure we keep improving the experience while also reducing our maintenance burden for the LTS and future releases of Ubuntu.

因此，虽然Linux Mint项目是在Ubuntu改动到了流行的chromium-browser时才采取了行动，但其实这只是引爆问题的临界点而已，而并不是针对这一个软件包而已。根据Linux Mint的说法，Canonical的这些举动 "could reduce access to free (as in beer) software and free (as in freedom) software（可能会减少免费软件和自由软件的使用）"。这不是一个突如其来的决定。早在一年前，Linux Mint项目就希望通过与Canonical合作来寻找合理的解决方案，然而这些对话似乎没有任何结果。事实上，目前还不清楚是否真的有过什么对话。

众所周知的是，当Ubuntu 20.04在之后一年发布时，安装Chromium的APT包仍然在未经用户同意（甚至不一定知道）的情况下安装了Snap版本。于是Linux Mint项目就兑现了之前的威胁。从Linux Mint 20开始，"Chromium不会是一个背着你安装Snapd的伪装包。相应地，它什么也不会安装，只会告诉你为什么它不安装软件，并告诉你去哪里来自己获得Chromium。" 此外，Linux Mint 20的APT包管理器 "会禁止安装snapd"。该项目似乎并没有直接禁止用户使用Snap（加入他们想要用的话），但需要用户明确声明他希望使用Snap，因为 "默认情况下，APT不会允许仓库包[代表你安装Snap]"。据推测，这个行为会适用于Ubuntu上游迁移到Snap的所有软件包，包括chromium-browser和gnome-software。

根据ZDNet最近的报道，这个决定似乎产生了效果，并促使Canonical至少开始讨论进行一些改变。ZDNet援引Canonical的一位代表的话说："We would welcome Linux Mint to engage with us and our community to discuss such topics, as we do with other distributions, and work together going forward."。

Canonical负责Ubuntu工程服务的社区经理Alan Pope专门提供了一个理解解释为什么要把Chromium迁移到Snap。不过，这个理由并没有引用VanDine在上面针对gnome-software所提到的说法：

Maintaining a single release of Chromium is a significant time investment for the Ubuntu Desktop Team working with the Ubuntu Security team to deliver updates to each stable release. As the teams support numerous stable releases of Ubuntu, the amount of work is compounded. Comparing this workload to other Linux distributions which have a single supported rolling release misses the nuance of supporting multiple Long Term Support (LTS) and non-LTS releases. [...]

A Snap needs to be built only once per architecture, and will run on all systems that support Snapd. This covers all supported Ubuntu releases including 14.04 with Extended Security Maintenance (ESM), as well as other distributions like Debian, Fedora, Mint, and Manjaro.

期待后续双方能达成一致解决这个问题，这里可能会有一些有趣的技术方面的改进。Linux Mint在其博客文章中提到了对Snap的各种改动建议，比如允许第三方运行独立的Snap包服务器，这就可能有助于达成解决方案。它提到："snap既可以作为客户端，也可以作为文件格式，只要它不把我们绑定到一个单一的商店里就好"。然而，这样做很可能与Canonical的战略目标背道而驰。

What's next

大家务必要认识到，从根本上来说，Snap这样的技术对于那些创建软件包的人来说是很有用的，包括专有软件供应商也可以受益。在这种情况下，问题似乎不是技术，而是Canonical对它的全面控制，以及通过控制APT来达成这个控制的方式。正如Linux Mint项目在其2019年的文章中所说。

[Snap] was supposed to make it possible to run newer apps on top of older libraries and to let 3rd party editors publish their software easily toward multiple distributions [...] What we didn't want it to be was for Canonical to control the distribution of software between distributions and 3rd party editors, to prevent direct distribution from editors, to make it so software worked better in Ubuntu than anywhere else and to make its store a requirement.

终归来说，这里有多种利益纠葛在一起，导致事情后续发展的不确定性。一方面，像Canonical这样的公司看到了控制应用程序分发的技术能带来的战略价值，并利用它在它希望看到变化的地方施加压力。另一方面，还有像Linux Mint这样的发行版，他们准备在技术被单一商业利益控制的情况下，积极阻止相关技术的发展。希望Linux Mint的这一最新举动能促使人们向更开放的方向转变，因为像Snap这样的打包系统如果能以开放的方式实现，对整个Linux社区来说都是一种胜利。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～