为什么Ubuntu转向Snappy软件包?


126

为什么Ubuntu会转储.deb软件包并转移到.snappy软件包?(至少目前,他们保留.deb软件包以进行正态分布)。.deb已经是那里最受欢迎的打包文件。

这样就可以了解Snappy软件包的格式。但是现有的deb软件包会发生什么?迁移到Snappy有明显的优势吗?值得付出痛苦吗?


链接
很烂

Answers:


144

Snappy试图解决Linux作为桌面操作系统的一个基本问题,即软件包可用性和软件包分发。但是,Snappy并非完全旨在替换deb。对齐和Debs相互配合。

我是Linux爱好者,也是Linux应用程序的项目经理。虽然我整体上喜欢Linux系统,但我鄙视软件包分发的当前状态。Snappy旨在解决这个基本问题。

在Linux中,软件包大部分是特定于发行版的(有可能使一个DEB在所有基于Debian的各种不同系统中运行,但在某些方面限制了您),不仅软件包是特定于发行版的。

如果我为Ubuntu 16.04创建一个deb软件包,则该软件包将不适用于任何版本的Ubuntu。我还必须输入14.04、15.04、15.10等。这些只是Ubuntu的Deb。我还需要为Debian做一个。然后,您需要为Fedora 21、22、23等制作RPM,而这些RPM甚至无法涵盖openSUSE。

这意味着如果我要发布应用程序的新版本,而不是等待发行版维护人员将其包含在存储库中(通常会花费大量的时间),那么我必须提供20多个软件包来覆盖大多数Linux发行版但这仍然无法涵盖所有​​内容。

Ubuntu的Snaps提供了一种创建可在每个支持Snaps的Ubuntu版本上运行的Snap的方法。不再是特定于发行版的发行版。

快照可以集成到其他发行版中。可能不再是特定于发行版的。

快照在一个由仓库开发人员维护的仓库中进行控制,因此当我们要发布新版本时,我们不必等待任何人。

本质上,我讨厌Linux软件包分发的所有内容都将由Snappy解决。尽管必须指出,这些问题也可以通过AppImagesFlatpaks解决。

TL; DR

Linux软件包分发对开发人员和用户都非常糟糕。Snappy(也称为AppImages和Flatpaks)旨在解决基于Linux的系统的这一基本问题。


这个问题确实是关于为什么要采取行动的问题,但是是否有人有兴趣了解更多有关Snaps是什么以及它们如何工作的信息。我创建了此视频以深入解释该结构。


12
天哪,您听起来很难,除非没有人支持这么多版本的Fedora,Debian或Ubuntu。到16.04退出时,15.04就是EOL。到Fedora 23推出时,F21还剩下不到一个月的生命,足以让人们跳过发行版。没关系。编写完基本的RPM规范文件或基本的Debian软件包后,其他发行版便进行了调整,然后只需为每个新发行版构建它们便是Jenkins的工作。
约翰·富兰克林

10
Ubuntu软件包适用于多种版本:14.04、15.10、16.04,有些仍继续支持旧的LTS,如仍支持的12.04。|| Fedora没有LTS,因此可以支持的版本更少,但仍然至少支持2个版本,可能支持3个版本。|| 听起来对您来说更好?A.为一个发行版制作同一应用程序每个版本的多个程序包,并为多个发行版执行该程序包。或者B.为您的应用的每个版本制作一个快照,并且可以在任何发行版和所说发行版的任何版本上使用。是的,在这种情况下,我投赞成票。
Michael Tunnell

4
@ user447607您误解了快照和快照。不会有很多冗余,会有运行时,并且会有使快照依赖于其他快照以节省空间的选项。实际上,这已经是可能的。Snappy是另一个处理快照的程序包管理系统,而apt仍然与DEB有关。快照不会替代DEB,而是会增加DEB,因此您将获得一种涵盖这两种方法的混合方法。实际上,可以通过现有的DEB自动生成快照。
Michael Tunnell

2
@konung Docker纯粹是容器化,正如Snaps所具有的那样,并且与系统核心组件集成。例如,Docker要求容器中包含所有内容才能使用它。但是,快照仅需要包含必需品,然后它可能会超出快照以利用其他功能。Snaps还具有更好的基础架构,因为Docker没有真正的更新机制,但是Snaps使用了与APT for Debian类似的软件包管理系统。我建议您查看我在原始帖子中链接的视频。我打算尽快制作一个更新的版本。
Michael Tunnell

6
@konung Snap不是容器。例如,很多人将它们与Docker相比较,但Docker是真正的容器,而Snaps却不是。捕捉类似于容器,但它们不是完整的容器,因为它们允许在限制范围之外进行异常。例如,settings / configs / data内容存储在/ home文件夹中的Snap内部。这样,您就可以拥有所有想要共享相同数据/配置的快照版本。
Michael Tunnell

20

很简单。Snappy软件包包含所有必需的文件,其中.deb软件包与其他软件包具有依赖性。

不利的一面是,snappy较大,因为它包含所有文件。但是最大的好处是您不会遇到其他软件包的麻烦,并且如果删除此软件包,则其他任何软件包都不会受到缺少依赖项的影响。


7
这也意味着安全噩梦。哦,请证明我错了……因为正确将是如此可怕。
于尔根A.艾哈德

27
因此,从本质上讲,他们采用Windows路径-具有讽刺意味的是,过去Linux-ers嘲笑了这一路径。
Pithikos

1
嘿,@JürgenA.Erhard,据我所知,每个软件包都有其自己的库,例如密码学,因此除了验证一个软件包(即自动编译)之外,您基本上必须单独处理每个软件包,这就是您的意思。 “安全噩梦”?
伊利亚

更正:“包含所有必需的文件”是不正确的,因为存在充当运行时的核心快照。但是,这是在原始答案之后添加的,因此在当时是正确的,但此后发生了很多变化。
Michael Tunnell

7

Snappy Personal,他们用于包管理/更新的新方法,旨在更快,更可靠,具有事务性并具有更强的安全性。

Snappy至少要进行一次桌面旋转-计划是将Ubuntu的Desktop-Next旋转从.deb切换到Snappy Personal。

.deb仍会存在,并且普通用户仍可以在将.deb转换为snappy时正常使用它。

Snappy将用于在ioT中统一软件包管理的概念,该ioT现在使用snappy作为其核心Os。此外,snappy提供了一种更好的更新方式,并且在更新/升级时摆脱了问题,因为它使用了整个映像的概念,这意味着更新将只是一件,因此绝不会失败

阅读这些文章以获取更多信息:

http://www.webupd8.org/2015/04/ubuntu-desktop-to-eventually-switch-to.html

http://www.itworld.com/article/2914850/linux/is-ubuntu-moving-away-from-deb-packages-here-is-the-complete-story.html

还有来自ubuntu的QA广播视频,它回答了很多问题 https://youtu.be/lHO8j8uo5Z4


9
他们为什么不能制作具有向后兼容性的.deb版本2软件包?为什么要在Linux社区中分裂?目前,计划是缓慢迁移到Snappy,除非最终失败。
Vishnudev K

他们希望在ioT中统一软件包管理的概念,该ioT现在使用snappy作为其核心Os。此外,snappy提供了一种更好的更新方式,在更新/升级时避免了问题,因为它使用了整个映像的概念,这意味着更新将只是一件,因此绝不会失败
Maythux 2015年

3
由于Linux中存在各种各样的打包方法(已经引起了第三方程序的问题),这已经很糟糕了,另一种方法只会造成更大的麻烦:-/
Wilf 2015年

@Maythux。什么是ioT?
TRiG

4
@Maythux xkcd.com/927
CVn

4

考虑迁移到活泼的Ubuntu的核心今天如果你正在考虑创造一些对他人使用,换句话说,一个产品

该软件以快照方式交付,鉴于其特点,我们可以确信安装和升级将按原始创建者的意图在每个系统上运行。其他特征是安全性,例如隔离的执行和与系统对话并配置已安装的快照的简洁接口。

要实现这样的目标,快照与debian软件包有很大的不同:

  • 快照驻留在系统确定的隔离位置,而debian软件包可以将文件传播到整个位置。
  • 没有用于快照的维护程序脚本。

回到最初使用不使用的问题,如果您打算用Ubuntu Core替换桌面,我建议您坚持使用常规的Ubuntu桌面。我个人很喜欢将Ubuntu Core称为“ 无内容发行版”,因为它本身没什么,但是提供了一个很好的构建基块来提供某些东西,这就是为什么它在当今的IoT中很流行的原因。


3
换句话说,它就像窗户一样吗?
Vishnudev K

1
这是一个广泛的问题。Windows特别做什么?
sergiusens

4
我在Windows中安装VLC,它安装了占用空间所需的所有软件包。在linux中,我们只得到我们没有的软件包。就更新和硬盘使用而言,这非常方便。
Vishnudev K

2
类似,是的。这与apk在手机上安装没什么不同。应用程序可以根据自己的依赖性进行演化。尽管有多种方法可以拆分,例如通过使用framework快照,但这需要严格的安全检查。与Windows的区别在于,这里没有安装程序可能会在他们想要的任何地方登陆。
sergiusens
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.