Linux Mint放弃Ubuntu Snap软件包

2020-07-09 02:01:32

LWN订户已向您提供以下仅限订阅的内容。数以千计的用户依赖LWN获取来自Linux和自由软件社区的最好消息。如果您喜欢这篇文章,请考虑接受右边的试用报价。感谢您访问LWN.net!

免费试用LWN 1个月:无需付款或信用卡。现在激活您的试用订阅,看看为什么成千上万的读者订阅LWN.net。

Linux Mint项目已经兑现了之前的威胁,积极阻止Ubuntu snap包在未经用户同意的情况下通过APT包管理系统安装。这一举动是Linux Mint on Snap对用户选择和软件自由影响的主要担忧的结果。Ubuntu的母公司Canonical似乎愿意找到一个解决方案来满足流行发行版的担忧--但它也有自己的利益需要考虑。

Linux Mint发行版基于Debian和Ubuntu,提供了来自这些项目的30,000多个包。这些包是使用两个上游发行版使用的众所周知的APT打包系统提供的。然而,Ubuntu在2014年开始使用一种名为Snap的技术与APT并行分发软件。

Snap是一个独立的软件包部署系统,旨在更轻松地管理Linux环境中应用程序的依赖项。Snap由Canonical开发,旨在使其软件包包含软件包运行所需的所有特定依赖项,并捆绑到单个文件系统映像中。这允许软件包在具有所需库的其他不兼容版本的系统上运行,或者甚至允许具有不同依赖关系的单个软件包的两个不同版本容易地共存于一台机器上。从本质上讲,它允许为每个架构创建一个包,该架构可以在任何常见的Linux发行版上运行。

该技术为Canonical和Ubuntu解决了重要的包管理问题。它还具有战略商业价值,因为它允许在与之竞争的发行版上安装Canonical管理的软件。Canonical想要解决的技术问题是简化对Ubuntu多个版本的软件包(如Chromium)的支持。严格依赖APT需要为每个Ubuntu版本维护独立的软件包,因为不同的Ubuntu版本附带了不同的、可能不兼容的库。这是Canonical宁可不愿处理的大量工作负载,Snap为其提供了出色的技术解决方案。

从商业角度来看,广泛采用Snap作为通用软件包分发技术将使Canonical在控制Linux软件分发方面处于有利地位。这一事实并没有被Canonical的竞争所忽视-红帽支持类似的Flatpak技术。然而,与Snap不同的是,Flatpak项目的目标是成为一个独立的社区和一个真正的上游开源项目,致力于提供所有人都可以使用的技术和服务,不受供应商的限制。

当Ubuntu将Chromium转移到Ubuntu19.10中的Snap发行版时,Linux Mint的问题达到了顶点。从表面上看,这本身并不是问题-Linux Mint项目总是可以开始提供自己的Chromium APT包。问题是决定在Ubuntu的上游改变Ubuntu铬浏览器apt软件包本身。以前,该软件包只需直接安装Chromium即可。有了这样的改变,它会先安装Snap包管理工具,然后再安装相当于Chromium包的Snap包,而不会让用户清楚地知道发生了什么。

这种行为并不局限于Chromium,Canonical也在其他软件包上使用这种方法,比如GNOME-SOFTWARE。决定使用APT安装第二个商业控制的软件包管理系统,然后由该系统安装用户想要的软件,这是与Linux Mint争论的中心。正如Linux Mint博客在进行Chromium更改时所报道的那样:

自安装Snap Store会覆盖我们的部分APT软件包基础,这是完全不可以的。这是我们必须停止的事情,这可能意味着Chromium更新和访问Linux Mint中的Snap Store的结束。

Linux Mint项目最近的决定不是关于Chromium或任何单一的软件包,而是关于Canonical正在采取的整个抓取和APT方法。Snap包实际上是黑盒;它们不能独立复制,因为包装数据仅由包装器制造商控制。此外,Snap包管理器锁定在Canonical的库(称为Snap Store)中,因此目前也不能选择独立的第三方Snap存储库。虽然可以从其他来源手动下载和安装Snap包,但这样做需要传递一个相当不祥的--危险标志。

根据Canonical工程经理Ken VanDine的说法,用Snap取代APT软件包的决定是出于效率考虑,并以有利于Canonical的方式施加压力。对于将GNOME-SOFTWARE APT软件包移动到Snap,VanDine说:

通过发布像Snap这样的关键应用程序,它将继续保持压力,以确保我们不断改善体验,同时也减轻了我们对LTS和Ubuntu未来版本的维护负担。

因此,虽然Linux Mint项目在Ubuntu的决定影响流行的铬浏览器包时采取了具体行动,但这似乎更多地是该项目的引爆点,而不是一个孤立的问题。根据该项目,Canonical的这些举措可能会减少免费(如啤酒)软件和免费(如免费)软件的使用。这也不是一个突然的决定-一年前,Linux Mint项目希望通过与Canonical合作找到一个合理的解决方案,但这些对话似乎没有取得任何结果。事实上,目前还不清楚是否发生了任何对话。

已知的是,一年后,当Ubuntu 20.04发布时,安装Chromium的APT软件包在未经用户同意(甚至不一定知情)的情况下仍然安装了Snap版本。作为回应,Linux Mint项目兑现了它之前的威胁;从Linux Mint20&34;Chromium开始,Chromium不是一个在背后安装Snapd的空包。它将是一个空软件包,它会告诉您为什么它是空的,并告诉您自己在哪里可以找到Chromium。此外,Linux Mint20;的APT软件包管理器将禁止安装SnapD。该项目似乎并没有明确禁止用户使用Snap(如果他们想要使用Snap),但这样做需要用户显式操作,因为在默认情况下,APT不会允许存储库软件包[to。据推测,这适用于Ubuntu迁移到Snap上游的任何软件包-包括Chrome浏览器和GNOME软件。

根据ZDNet最近的报道,这一决定似乎产生了影响,并促使Canonical至少讨论了路线的改变。ZDNet援引Canonical的一名代表的话说:

我们欢迎Linux Mint与我们和我们的社区一起讨论这样的话题,就像我们对其他发行版所做的那样,并共同努力向前发展。

Canonical的Ubuntu工程服务社区经理Alan Pope专门为Chromium迁移到Snap提供了理由。然而,辩解并没有引用VanDine就GNOME-SOFTWARE等其他软件包所表达的保持压力的想法:

对于Ubuntu桌面团队与Ubuntu安全团队合作,为每个稳定版本提供更新,维护单一版本的Chromium是一项巨大的时间投入。由于团队支持大量稳定的Ubuntu版本,因此工作量很大。将此工作负载与其他只有一个受支持的滚动版本的Linux发行版进行比较,会忽略支持多个长期支持(LTS)和非LTS版本的细微差别。[.]。

每个体系结构只需构建一次快照,并将在所有支持Snapd的系统上运行。这涵盖了所有受支持的Ubuntu版本,包括带有扩展安全维护(ESM)的14.04,以及其他发行版,如Debian、Fedora、Mint和Manjaro。

看看这会带来什么,以促进各方之间的解决,这将是一件有趣的事情。Linux Mint在其博客文章中提到了Snap的各种变化,例如允许第三方运行独立的Snap包服务器,这可能有助于达成解决方案。正如该项目所写的,如果Snap不把我们锁在一家商店里,它可以同时作为客户端和文件格式工作。然而,这样做很可能与Canonical的战略目标背道而驰。

重要的是要认识到,从根本上说,像Snap这样的技术对于那些创建软件包的人是有用的,包括专有软件供应商。在这种情况下,问题似乎不在于技术,而在于Canonical对它的独家控制--以及它通过APT引入的方式。正如Linux Mint项目在其2019年的帖子中所说的那样:

[Snap]本应使在旧库上运行较新的应用程序成为可能,并允许第三方编辑器轻松向多个发行版发布他们的软件[.]。我们不希望的是Canonical控制软件在发行版和第三方编辑器之间的分发,防止编辑直接分发,让软件在Ubuntu中比在其他任何地方都能更好地工作,并将其存储作为一项要求。

归根结底,这里有多种利益在起作用,导致事情将如何发展的不确定性。一方面,像Canonical这样的公司看到了控制应用程序分发背后的技术的战略价值,并在它希望看到变化的地方利用它来施加压力。另一方面,您有像Linux Mint这样的发行版,它们准备在该技术由单一商业利益集团控制时主动阻止该技术。希望Linux Mint的这一最新举措将推动一个更加开放的变化,因为像Snap这样以开放方式实现的打包系统将是整个Linux社区的胜利。

你喜欢这篇文章吗?请接受我们的试用订阅优惠,以便能够看到更多类似的内容并参与讨论。