Flatpak原理🔗

本页面简单介绍了Flatpak内部工作原理。虽然仅仅是使用Flatpak没必要熟悉这些，但是有些人可会会觉得这很有趣。从用户和应用开发者的角度来看，了解Flatpak的体系结构还有助于更好地理解它的工作方式和原因。

应用级Git🔗

Flatpak is built on top of a technology called OSTree, which is influenced by and very similar to the Git version control system. Like Git, OSTree allows versioned data to be tracked and to be distributed between different repositories. However, where Git is designed to track source files, OSTree is designed to track binary files and other large data.

Internally, Flatpak therefore works in a similar way to Git, and many Flatpak concepts are analogous to Git concepts. Like Git, Flatpak uses repositories to store data, and it tracks the differences between versions.

With Flatpak, each application, runtime and extension is a branch in a repository. An identifier triple, such as com.company.App/x86_64/stable is a reference to that branch. The output of a Flatpak build process is a directory of files which is committed to one of these branches.

使用Flatpak安装应用时，会将其从远程仓库中拉入到本地仓库中的新分支。 然后生成从文件系统指向仓库的链接（这些链接是快速解析和高效利用的磁盘空间`硬链接 <https://en.wikipedia.org/wiki/Hard_link>`）。 换句话说，安装的每个应用程序都存储在本地版本控制仓库中，然后映射到本地文件系统。

因此，版本跟踪是Flatpak架构的核心部分，这使得更新软件非常高效。 版本控制也使回滚成为可能，因此如果需要，可以很容易地回滚到以前的版本。

将应用程序存储在本地OSTree存储库中具有其他优点。 例如，它允许对存储在磁盘上的文件去重，所以属于多个应用程序（或运行时）的同一文件仅存储一次。

This blog post explains the underlying structure of a Flatpak repository in more detail.

Conditional permission system🔗

Since Flatpak 1.17.0, conditional permissions allow permissions to be granted only when certain runtime conditions are satisfied, with fallback to unconditional grants for compatibility with older versions.

Permissions are internally represented as:

  • unconditionally allowed or denied

  • a reset flag indicating whether the current layer overrides rules from lower layers

  • a set of conditional rules under which the permission may be allowed

For example:

  • --socket=NAME unconditionally allows the permission and resets any previously defined rules for that permission

  • --nosocket=NAME unconditionally denies the permission and resets any previously defined rules

  • --socket-if=NAME:CONDITION adds a conditional rule without resetting existing rules

Conditions may be negated using !.

Multiple conditional rules can be specified for the same permission. In this case, the permission is granted if any condition evaluates to true.

Duplicate conditions are ignored. The order of conditions does not affect evaluation.

If no conditional rules are present, the permission is granted only if it is unconditionally allowed.

If conditional rules are present, the permission is granted if any condition evaluates to true, and denied otherwise, unless it is also unconditionally allowed.

If an unconditional entry follows a conditional entry for the same grant in commandline flags, the earlier unconditional entry is treated as backwards compatibility fallback and does not affect the final permission state.

A --socket-if=NAME:CONDITION is written in the metadata as:

sockets=NAME;if:NAME:CONDITION;

Permissions are written to metadata using the following rules:

  • Unconditionally allowed permissions are written as NAME

  • Unconditionally denied permissions are written as !NAME

  • Conditionally allowed permissions are written as:

    • unconditional NAME entry for compat

    • if:NAME:CONDITION entries

If the permission resets previously defined rules, an explicit !NAME entry is written first, followed by the unconditional NAME entry and then the if:NAME:CONDITION entries. This is omitted when saving an application's own metadata, as opposed to overrides.

When parsing metadata, a non-negated unconditional NAME entry appearing before a if:NAME:CONDITION entry is treated as a compatibility fallback and does not affect the final permission state. Eg. sockets=x11;if:x11:!has-wayland; is effectively treated as if:x11:!has-wayland in Flatpak versions supporting conditional permissions.

基础技术🔗

Flatpak使用了许多已经存在的技术。如：