快照程序包如何处理共享依赖关系？

问题描述

通过允许每个包都有自己的依赖副本，snap打包格式最终使我们摆脱了依赖困境。我对如何执行此操作的技术细节感兴趣。如何处理：

• 快照取决于当前版本中已经通过deb软件包安装的库的版本？它会忽略已安装的库吗？

• 指定相同库的相同版本的不同快照？它会以某种方式进行重复数据删除吗？

• 对核心库的更新可能会被很多快照使用？ OpenSSL是一个巨大的痛点。

xdg-app的名称为a “runtime”：

A fundamental concept in xdg-app is the runtime/application split. Every app depends on a runtime, which supplies the core libraries that the app relies on. Runtimes are typically shared by many applications, but a user can have multiple runtimes installed at the same time.

似乎对于OpenSSL，它将是xdg-apps中运行时的一部分，因此，对OpenSSL的更新应该透明地影响使用同一运行时的所有xdg-apps。

最佳思路

前两种情况以巧妙的方式处理。

One of the interesting features talked about is deduplication support for content within Snap packages. Snaps would be automatically deduplicated of common files shared between snaps based upon their file hashes. There would be de-duplication on the file-system layer, de-duplication on snap downloads (with server support), and perhaps de-duplication of mapped libraries from the linker. Deduplication is a big work item and likely will take a while to implement fully, but it’s an interesting goal nevertheless.

来源：http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Snappy-Deduplication

至于第三种情况，它们与您提到的运行时类似：

There are three layers that make up a snappy machine: the system layer, provided by Canonical, a layer of frameworks that extend the base system produced by vendors in collaboration with Canonical, and a set of snappy applications, provided directly by vendors. Updating any piece just means using the new version of a read-only image. Reverting to a previous version is just as easy.

来源：http://www.ubuntu.com/cloud/snappy

尚无描述框架的好的文档，主要是因为它们似乎仍在确定框架的范围。这是他们的邮件列表的摘录，可能有助于澄清问题。

I am experimenting with Frameworks to essentially extend the Snappy base system by software and services which lots of snaps require but should not be included in any and each snap due to update issues and size. The best example i have for this, is the openssl binary. Many snaps need this to generate and validate keys and certificates.

The other issue i tied to solve with a framework is the access to system wide resources, mote notably ports. Eg, a web server framework would provide ways for other snapps to inject their web service api and end points via reverse proxy into the framework running the web server.

I was told on IRC that i am kind of abusing the framework concept, but still these two issues come up on my desk often.

来源：https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000442.html

次佳思路

我认为快照不会检查已经安装了哪些依赖项。它仅包括其所有依赖关系和运行时(这部分是为什么LibreOffice snap为287 MB而flatpak为200MB的原因)。

快照几乎包含了软件运行所需的所有内容。我认为快照之间不会共享任何内容。

但是，当快照更新时，它将仅下载新的依赖关系，而不下载整个快照。

第三种思路

为了进一步说明快照打包处理共享依赖项的方式。

Snaps include pretty much everything the software needs to run. I don’t think anything gets shared between snaps.

答案之一中的这一说法部分正确，但是除核心快照外，所有已安装的快照软件包都依赖于两个软件包，其中一个是核心快照。

1. snapd-默认安装在16.04和更高版本中

2. 核心-(核心快照)在安装第一个已安装的快照软件包时自动下载并安装

除核心本身以外的所有快照程序包都取决于核心快照。如果核心快照有任何问题，那么其他一些或全部快照将不起作用。可以通过以下两种方式解决核心卡扣问题。

1. 更新核心捕捉。即使这行不通，运行以下命令的结果也会提供有助于解决问题的其他信息。

   sudo snap refresh core  
   

2. 卸载核心快照和所有快照软件包，然后重新安装它们。

   sudo snap remove core snap-package1 snap-package2  
   sudo snap install core snap-package1 snap-package2
   

参考资料

• How do snap packages handle shared dependencies?