This is supposed to list all the currently loaded "non-standard" gl drivers.
If FLATPAK_GL_DRIVERS is set, then that is used, otherwise it looks
for an nvidia driver and if so, uses that, and always adding "default"
at the end which is meant to resolve to a stable mesa fallback build, as
well as "host" which can be used if you have a host-side driver
as an unmaintained extension.
If directory is "foo" and the extension id ends with ".ext" and
subdirectory-suffix is "sub" then the extension point will
be "/usr/foo/ext/sub" rather than just "/usr/foo/ext".
This is very useful when the extension point naming scheme is
"reversed". For instance, this happens for the /usr/share/themes directory.
An extension point for a gtk3 theme would be in /usr/share/themes/$NAME/gtk-3.0,
which could be achived by using subdirectory-suffix=gtk-3.0.
If your extension points set this, then each extension will have
the corresponding subdirectory added to LD_LIBRARY_PATH.
We also support a priority property in the ExtensionOf group
in the extensions themselves to set the search order.
If we sort, or subset the extensions we use, then we can't just
set need_tmpfs on the first one, instead do the checking
for the first one when we're applying the extensions.
On unmonitored systems (if the session helper is not available), we
currently decide whether to create a symlink or a read-only bind mount
for /etc/localtime based on whether that's a symlink in the host or
not, but we don't check whether that symlink would be reachable in
the sandboxed environment, which might lead to bad situations.
This patch adds some extra checks relying on GFile's API to check
whether that symlink would be reachable before making the final
decision: if it's not, then do a bind mount despite of the file
being a symlink in the host.
https://github.com/flatpak/flatpak/issues/409
In extract_extra_data(), flatpak currently returns TRUE whenever
flatpak_repo_get_extra_data_sources() returns NULL, which is correct
most of the times since that's usually caused by the extra-data
finish-args argument not being present.
However, that operation relies on OSTree's ostree_repo_load_variant()
too, which could fail for unrelated reasons. And in those cases flatpak
would still keep returning TRUE here even in cases where the extra-data
sources could be there, but an error happened while retrieving it.
This seems to be a bug leading to unlikely -yet possible- situations,
where the user would end up with an "external app" like Spotify reported
to be succesfully installed but without the files/extra directory, which
is useless.
Just because stdout/stderr happen to be going to a terminal doesn't
necessarily mean that we want the command launched by HostCommand
to take ownership of the terminal - in the case where 'flatpak run'
is launched from a terminal, stderr will typically be left pointing
to the terminal for any command. In that case the terminal already
has a controlling process, and TIOCSCTTY will fail; avoid scary
messages by making the failure only a g_debug()
It turned out that some sources where bind-mounted read-write
which should have been read-only:
* Extensions
* Fonts
* resolv.conf
* localtime
* machine-id
Many of these are not generally writable by the user, but
some are, which is pretty bad. For instance if the an
app is user-installed it will be able to write to its
locale data.
We fix this by using --ro-bind where needed.
Even without -d this shows the whole ref, as well
as the source of the app (user/system) and if it
is a runtime.
This is important now as the default is to show
both user and system and both apps and runtime.
We make /etc just a symlink to /usr/etc when we're building a runtime
and /etc is supposed to be writable. Otherwise the bind-mount we
normally have there don't allow use to replace existing files in /etc.
The socket directory then ended up in $HOME which was read-only, so
we couldn't create the socket. We solve this by putting the sockets
in a subdirectory and always making this directory writable in the
proxy.
