For now, this just prints bits of summary information in
human-readable form. This command could grow over time
to provide other functionality for managing local repositories.
Show the same data the we show for other refs, when we
list extensions. In addition, show the subpaths if there
are any. Note that this reveals that the installed size
for subpath'ed extensions is misleading, since it is
the installed size for the full extension.
I have multiple branches of org.gnome.Platform install system-wide,
and non per-user. And flatpak info gives me:
flatpak info org.gnome.Platform
-> not installed
flatpak info --system org.gnome.Platform
-> multiple branches
This confusing behavior comes from the fact that we are querying
multiple locations and are not careful enough to collate the
errors we get properly. This commit changes things so that we
keep querying the next location as long as we get a 'not installed'
error, and we report the first 'multiple branches' error we get.
The --app and --runtime options are not really useful
for flatpak info, since you need to specify a full ID
anyway, and it is highly unlikely that you will have
ID clashes between apps and runtimes. Also, the options
are documented in a confusing way.
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.
Alexander Larsson