清单🔗
The input to flatpak-builder
is a JSON or YAML file that describes the
parameters for building an application, as well as instructions for each of
the modules that are to be built. This file is called the manifest.
这个页面提供了如何使用清单文件的信息和指南,包括需要指定的最常用参数的详解。读这一章节之前要求已经学习过 构建你的第一个flatpak应用 并且熟悉 Flatpak Builder 。
Manifest files should be named using the application ID. For example, the
manifest file for GNOME Dictionary is named org.gnome.Dictionary.yml
. This
page uses this manifest file for all its examples.
一个完整的属性列表可以在清单文件中指明,可以在 Flatpak Builder命令行参考文档 和 flatpak-manifest
找到。
基本属性🔗
Each manifest file should specify basic information about the application that
is to be built, including the id
, runtime
, runtime-version
,
sdk
and command
parameters. These properties are typically specified
at the beginning of the file.
举个例子,GNOME Dictionary的清单文件包含:
id: org.gnome.Dictionary
runtime: org.gnome.Platform
runtime-version: '45'
sdk: org.gnome.Sdk
command: gnome-dictionary
指明runtime和runtime版本可以在用户的系统上自动安装你的应用需要的运行时。
文件重命名🔗
Exports are application files that are made available to the host, and include
things like the application's .desktop
file and icon.
The names of files that are exported by a Flatpak must be prefixed using the
application ID, such as org.gnome.Dictionary.desktop
. The best way to
do this is to rename these files directly in the application's source.
如果无法使用应用ID重命名导出文件, flatpak-builder
允许在构建过程中重命名。可以通过在清单文件中指明下面的属性来实现:
rename-icon
- 重命名应用图标rename-desktop-file
- 重命名.desktop
文件rename-appdata-file
- rename the MetaInfo file
每个属性都可以接受源文件重命名。 flatpak-builder
会自动重命名他们以匹配应用ID。注意这种重命名方法可能产生内部命名冲突,所以在文件树中进行重命名是最可靠的方法。
Finishing🔗
flatpak应用默认运行在很有限的主机环境里面,但是应用需要访问沙箱之外的资源。finishing是用于指明应用沙箱权限的一步,用于访问外界资源。
finishing清单节点使用 finish-args
属性,可以在Dictionary的清单文件见到:
finish-args:
# X11 + XShm access
- --share=ipc
- --socket=fallback-x11
# Wayland access
- --socket=wayland
# GPU acceleration if needed
- --device=dri
# Needs to talk to the network:
- --share=network
# Needs to save files locally
- --filesystem=xdg-documents
Guidance on which permissions to use can be found in the 沙箱权限.
cleanup🔗
The cleanup property can be used to remove files produced by the build process that are not wanted as part of the application, such as headers or developer documentation. Two properties in the manifest file are used for this. This can be either done for each modules in which case only names created by that module will be matched or at the toplevel which will match anything created in the entire manifest.
Items starting with / are taken to be relative to the prefix, so
/include
will cleanup /app/include
, otherwise it matches the
basename.
First, a list of filename patterns can be included:
cleanup:
- '/include'
- '/bin/foo-*'
- '*.a'
A cleanup with *
, at the module level will cleanup all artifacts
built from that module. This is often useful for build dependencies of
a module that does not need to be shipped in the final Flatpak package:
cleanup:
- '*'
The cleanup-commands property can be a list of cleanup commands:
cleanup-commands:
- 'find /app/bin -mindepth 1 -maxdepth 1 -name 'rpm*' ! -name 'rpm2cpio' -delete'
Note that, instead of cleaning up unnecessary files, it is often better
to build less components through config-opts, build-commands, make-args
.
For example, if the application does not need documentation files or
manpages, it's best to stop building them. This should make the build
faster in some cases and reduce the need for excessive cleanups.
模块🔗
这个模块列表作为构建过程的一部分,指明了每个模块。其中一个模块是应用本身,其他的是依赖和库,作为flatpak的一部分进行绑定。当应用比较简单的时候,只有一到两个模块,因此有较短的模块节点,一些应用会有大量的模块需要绑定,因此会有较长的模块节点。
Modules are built in the order they are declared in the manifest. If any module changes, that module and all the subsequent modules below it will be rebuilt, otherwise it should use the cache.
The general recommendation is to place the "main" module, usually the module for the main application as the last module in the manifest but if there is a module which gets updated often and is independent from the rest, that module can also be placed as the last module to avoid rebuilding everything else.
Modules can either be nested to clearly show the dependency structure or be linearly declared.
# Nested
finish-args:
- --share=ipc
- --socket=fallback-x11
- --socket=wayland
- --socket=pulseaudio
modules:
- name: video-player-app
buildsystem: meson
config-opts:
- --buildtype=release
cleanup:
- /share/man
sources:
- type: archive
url: https://example.com/release.tar.gz
sha256: 216656c4495bb3ca02dc4ad9cf3da8e8f15c8f80e870eeac8eb1eedab4c3788b
modules:
- name: libmpv
buildsystem: meson
config-opts:
- -Dlibmpv=true
sources:
- type: archive
url: https://example.com/mpv.tar.gz
sha256: 2ca92437affb62c2b559b4419ea4785c70d023590500e8a52e95ea3ab4554683
modules:
- "shared-modules/lua5.1/lua-5.1.5.json"
- name: libv4l2
buildsystem: meson
sources:
- type: archive
url: url: https://example.com/libv4l2.tar.gz
sha256: 0fa075ce59b6618847af6ea191b6155565ccaa44de0504581ddfed795a328a82
# Linear
finish-args:
- --share=ipc
- --socket=fallback-x11
- --socket=wayland
- --socket=pulseaudio
modules:
- "shared-modules/lua5.1/lua-5.1.5.json"
- name: libv4l2
buildsystem: meson
sources:
- type: archive
url: url: https://example.com/libv4l2.tar.gz
sha256: 0fa075ce59b6618847af6ea191b6155565ccaa44de0504581ddfed795a328a82
- name: libmpv
buildsystem: meson
config-opts:
- -Dlibmpv=true
sources:
- type: archive
url: https://example.com/mpv.tar.gz
sha256: 2ca92437affb62c2b559b4419ea4785c70d023590500e8a52e95ea3ab4554683
- name: video-player-app
buildsystem: meson
config-opts:
- --buildtype=release
cleanup:
- /share/man
sources:
- type: archive
url: https://example.com/release.tar.gz
sha256: 216656c4495bb3ca02dc4ad9cf3da8e8f15c8f80e870eeac8eb1eedab4c3788b
可以看出,每个列出的模块有一个 name
(可以自由分配)和一个 sources
列表。每个source都有一个 type
,可用的type有:
archive
-.tar
or.zip
归档文件
git
- Git 仓库
bzr
- Bazaar 仓库
file
- local/remote files (these are copied into the source directory)
dir
- local directories (these are copied into the source directory)
script
- 一个shell命令数组(这些都被放在shell脚本文件里)
shell
- 再源码抽取期间运行的一组shell命令
patch
- 补丁(用于源代码目录)
extra-data
- 在安装时下载的数据;可以包含归档文件或者package文件
Different properties are available for each source type, which are listed in the Module Sources.
受支持的构建系统🔗
模块可以用多种构建系统构建,包含:
一个“简单的”构建方法,需要指定一系列命令。
Each of the above buildsystem sets up the installation prefix, libdir
etc. and runs a series of commands to configure (meson setup
, or
./autogen.sh, ./configure
or cmake
), build, install
(ninja install, make install
etc.) and optionally run tests
(make check, ninja test
etc.).
Thus they can also be achieved by using the simple
buildsystem and
manually specifying the commands.
备注
Using the proper buildsystem is almost always preferred rather than manually handling the correct setup.
An example is provided below.
# Using autotools without configure
- name: ffnvcodec
buildsystem: autotools
no-autogen: true
make-install-args:
- PREFIX=/app
sources:
- type: git
url: https://github.com/FFmpeg/nv-codec-headers.git
commit: 43d91706e097565f57b311e567f0219838bcc2f6
tag: n11.1.5.3
# Using meson buildsystem
- name: libdrm
buildsystem: meson
builddir: true
config-opts:
- -Dtests=false
sources:
- type: git
url: https://gitlab.freedesktop.org/mesa/drm.git
tag: libdrm-2.4.124
# Using simple
- name: ffnvcodec
buildsystem: simple
build-commands:
- make -j$FLATPAK_BUILDER_N_JOBS PREFIX=/app install
sources:
- type: git
url: https://github.com/FFmpeg/nv-codec-headers.git
commit: 43d91706e097565f57b311e567f0219838bcc2f6
tag: n11.1.5.3
- name: libdrm
buildsystem: simple
build-commands:
- meson setup builddir --prefix=/app --libdir=/app/lib -Dtests=false
- ninja -C builddir install
sources:
- type: git
url: https://gitlab.freedesktop.org/mesa/drm.git
tag: libdrm-2.4.124
Flatpak Builder Tools🔗
Flatpak Builder Tools (or flatpak-builder-tools) is a collection of scripts to aid using flatpak-builder. In this repository, each directory contains instructions to generate a manifest for the respective platform.
实例清单文件🔗
Flathub hosts a large collection of applications and the respective manifests can be browsed and searched via GitHub.