One benefit here becomes immediately obvious - `flatpak_fail()` was lacking
`G_GNUC_PRINTF` which meant we missed a lot of type checking. Fix up the
callers.
If you do something like:
flatpak build --talk-name=org.foo.Bar appdir
Then we now spawn a dbus proxy for the app.
However, we don't do this by default, even if the
runtime or the app metadata allows this, because
we want builds to normally be disconnected from
the build host.
This is a major change in the OCI support, as the format of the OCI image
registries changed. Instead of now having a "ref" file for each image
in the repo it has a single index json file, where the ref name is now
a per-image annotation.
This allows us to support OCI much better, as we can now use the actual
flatpak ref as the OCI ref name, and we can find all the flatpak refs
in a remote.
So, with this you can just use:
flatpak remote-add --oci remote-name URL
and then you can use the regular flatpak operations on the remote.
Currently if you pass flatpak-run an app that's not installed it prints
an error message to that effect, but if you pass it a runtime that's not
installed (and use the full ref format, e.g.
runtime/org.gnome.Sdk//master) it prints this message and crashes:
(flatpak run:15104): GLib-CRITICAL **: g_propagate_error: assertion 'src != NULL' failed
flatpak:ERROR:app/flatpak-main.c:394:flatpak_run: assertion failed: (success || error)
This commit makes flatpak print the appropriate error message, while
still printing an "app not found" error if the user didn't specify
whether the ref is an app or runtime.
In case you happen to have a reference A with a related reference
B (say a runtime and a GL extension), and they come from different
remotes, then updating A should not cause B to update from the same
remote as A, but rather the current remote.
When we update an app and add updates for all the related
operations, such as locates, and it is already installed,
make sure we inherit the current subpaths rather than
use the default ones.
Fixes https://github.com/flatpak/flatpak/issues/587
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.
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.
Before this commit
$ flatpak install --arch someArch --from some.flatpakref
Would completely ignore the arch argument and only install for the
default flatpak architecture. Since flatpakref files don't include
an arch field, there's no reason we can't attempt to install the
arch specified on the command line.
This change fixes GCC compiler warnings where a cleanup function was
specified on an uninitialised pointer, which in the view of GCC could
result in an errornous free of uninitialised memory, if the functions
that initialise them do not return NULL.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
If the bundle contains an origin link we can now install related
things from it, such as locale data.
You can also build the bundle with --runtime-repo=URL, where the url
points to a flatpakrepo file for a repo with runtimes. This works
similar to the RuntimeRepo= feature in flatpakref files.
