8a59927fde
Some builtin flatpak commands work on a single installation, and others
work on multiple installations (such as the remotes command that lists
both system and user remotes). Currently flatpak_option_context_parse()
only supports returning one installation to its caller, and any commands
that want to support multiple installations have to implement that
themselves which leads to a lot of code duplication.
This commit changes flatpak_option_context_parse() to take three new
flags:
* FLATPAK_BUILTIN_FLAG_ONE_DIR maintains the old behavior by
returning one installation (i.e. user if --user was passed, system if
--system, etc.).
* FLATPAK_BUILTIN_FLAG_STANDARD_DIRS will get all the installations
specified by the options, or the user and system ones if none were.
* FLATPAK_BUILTIN_FLAG_ALL_DIRS includes non-default system
installations along with the user and system ones if none were
specified.
These flags also affect what options are parsed and whether the
directories are ensured to exist, so it makes sense in some
circumstances for callers to pass a NULL out_dirs even when not using
FLATPAK_BUILTIN_FLAG_NO_DIR.
This commit also changes all the callers of
flatpak_option_context_parse() so they maintain their behavior. The only
functional change introduced by this is that using --installation
multiple times for commands that only support one now leads to an
error emitted by flatpak rather than by g_option_context_parse().
A follow-up commit will use this refactoring to make many commands
behave more intelligently in determining which installation to use.
Closes: #1205
Approved by: alexlarsson
Flatpak is a system for building, distributing and running sandboxed desktop applications on Linux.
See http://flatpak.org/ for more information.
Read documentation for the flatpak commandline tools and for the libflatpak library API.
INSTALLATION
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, Arch completely
disables user namespaces, while Debian supports unprivileged user
namespaces, but only if you turn on the
kernel.unprivileged_userns_clone sysctl.
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.