48ceed70be
Currently Flatpak reads a repo metadata key called "xa.collection-id" to decide whether to configure a collection ID on a remote. This commit drops support for xa.collection-id and replaces it with ostree.deploy-collection-id, which is a key defined by OSTree but so far only implemented here. The reason for the change is so that collection IDs can only be deployed to users running recent versions of Flatpak and OSTree. The current situation is that Endless wants to deploy collection IDs (and therefore support for doing USB updates) to users, but servers such as Flathub can't safely set xa.collection-id in their metadata, because many users are still using old versions of Flatpak and OSTree[1] which would hit various bugs[2][3][4] on the P2P code paths that are enabled by collection IDs. Defining a new key means that only users running recent (as-yet-unreleased) versions of Flatpak and OSTree will pay attention to it and deploy the collection ID, leaving the users on old versions unaffected. The reason this metadata key is being defined at the level of OSTree instead of Flatpak, is that OSTree may want to implement it in the future. The functionality of deploying a collection ID by setting the "deploy-collection-id" key in the config on the server side (which in turn causes ostree.deploy-collection-id to be set) is already covered by the unit tests in test-update-remote-configuration.sh; this commit just tweaks them to use the new key. Another solution I proposed to this problem was to have a key "eos.collection-id" which would only be understood by the Endless fork of Flatpak, and use that temporarily until enough people are running recent versions of Flatpak, at which point "xa.collection-id" can be used. But this solution (abandoning xa.collection-id upstream) allows us to avoid that migration step and leave users on old versions of Flatpak completely unaffected. [1] https://ahayzen.com/direct/flathub.html#downloadsbyflatpakstacked [2] https://github.com/ostreedev/ostree/commit/e4e6d85ea [3] https://github.com/flatpak/flatpak/commit/5813639f [4] https://github.com/flatpak/flatpak/commit/5b21a5b7
Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux.
See https://flatpak.org/ for more information.
Community discussion happens in #flatpak on Freenode and on the mailing list.
Read documentation for the flatpak commandline tools and for the libflatpak library API.
Contributing
Flatpak welcomes contributions from anyone! Here are some ways you can help:
- Fix one of the issues and submit a PR
- Update flatpak's translations and submit a PR
- Update flatpak's documentation, hosted at http://docs.flatpak.org and developed over in flatpak-docs
- Find a bug and submit a detailed report including your OS, flatpak version, and the steps to reproduce
- Add your favorite application to Flathub by writing a flatpak-builder manifest and submitting it
- Improve the Flatpak support in your favorite Linux distribution
Hacking
Flatpak uses a traditional autoconf-style build mechanism. To build just do
./configure [args]
make
make install
Most configure arguments are documented in ./configure --help. However,
there are some options that are a bit more complicated.
Flatpak relies on a project called
Bubblewrap for the
low-level sandboxing. By default, an in-tree copy of this is built
(distributed in the tarball or using git submodules in the git
tree). This will build a helper called flatpak-bwrap. If your system
has a recent enough version of Bubblewrap already, you can use
--with-system-bubblewrap to use that instead.
Bubblewrap can run in two modes, either using unprivileged user
namespaces or setuid mode. This requires that the kernel supports this,
which some distributions disable. For instance, Debian and Arch
(linux kernel v4.14.5 or later), support user namespaces with the kernel.unprivileged_userns_clone sysctl enabled.
If unprivileged user namespaces are not available, then Bubblewrap must be built as setuid root. This is believed to be safe, as it is designed to do this. Any build of Bubblewrap supports both unprivileged and setuid mode, you just need to set the setuid bit for it to change mode.
However, this does complicate the installation a bit. If you pass
--with-priv-mode=setuid to configure (of Flatpak or Bubblewrap) then
make install will try to set the setuid bit. However that means you
have to run make install as root. Alternatively, you can pass
--enable-sudo to configure and it will call sudo when setting the
setuid bit. Alternatively you can enable setuid completely outside of
the installation, which is common for example when packaging Bubblewrap
in a .deb or .rpm.
There are some complications when building Flatpak to a different
prefix than the system-installed version. First of all, the newly
built Flatpak will look for system-installed flatpaks in
$PREFIX/var/lib/flatpak, which will not match existing installed
flatpaks. You can use --with-system-install-dir=/var/lib/flatpak
to make both installations use the same location.
Secondly, Flatpak ships with a root-privileged policykit helper for
system-installation, called flatpak-system-helper. This is dbus
activated (on the system-bus) and if you install in a non-standard
location it is likely that this will not be found by dbus and
policykit. However, if the system installation is synchronized,
you can often use the system installed helper instead - at least
if the two versions are close in versions.