FLATPAK_ERROR_ALREADY_INSTALLED can be returned from, for example,
flatpak_installation_add_remote(), so document that it applies to
remotes not just apps and runtimes.
This will be used for parental controls, and potentially other reasons
for denying installation of an app.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This adds a new error to FlatpakError and uses it everywhere a ref is not
found, either locally or in a remote. This should hopefully be more useful than
the status quo of either returning FLATPAK_ERROR_INVALID_DATA or
G_IO_ERROR_NOT_FOUND or something else. Technically this is an API break but it
seems worth the risk. I checked gnome-software which does not seem affected by
this, and I checked eos-updater which does check for G_IO_ERROR_NOT_FOUND in
one place that will be affected by this but we can patch that.
Closes: #2895
Approved by: matthiasclasen
If the user (erroneously) runs as root while modifying their user
installation, e.g. with "sudo flatpak --user install ...", this can
cause "permission denied" errors later on when they try to operate on
the installation as their own user. So refuse to execute a transaction
on a user-owned installation as root. Root can still operate on their
own per-user installation.
This approach does have a weakness: if flatpak is running as root when the user
installation is first created, it will be owned by root and therefore
avoid this check. I'm not sure what could be done about that.
Fixes https://github.com/flatpak/flatpak/issues/2565Closes: #2575
Approved by: alexlarsson
Ostree just gives us a generic G_IO_ERROR_FAILED (boo!),
so we need to scrape the message to infer that this was
out-of-space. Translate this to an explicit error code
that we handle in the UI.
Closes: #2477
Approved by: alexlarsson
Add FLATPAK_ERROR_INVALID_DATA and use if for cases where
the incoming data for an update or install is faulty, and
add FLATPAK_ERROR_UNTRUSTED, FLATPAK_ERROR_SETUP_FAILED and
FLATPAK_ERROR_EXPORT_FAILED to cover more error conditions.
Closes: #2150
Approved by: alexlarsson
This will allow us to return anything in the FlatpakError domain using
g_dbus_method_invocation_return_gerror().
Closes: #1965
Approved by: alexlarsson
We only checked this in transaction. This is now the recommended way to installation
via libflatpak too, but if you use the old API this check also ensures that
installation fails if the required version is too old.
Also, we add a specific error code for this so callers can check for it.
Fixes https://github.com/flatpak/flatpak/issues/881Closes: #1755
Approved by: alexlarsson
We add an error signal to Transaction that the calle (cli) handles. It
decides what to do with the error and whether to continue or abort.
A new error ABORTED is returned from flatpak_run() to indicate
that it errored out because you chose to abort. We also add a new
error SKIPPED that we use to report that some operation is skipped
(due to earlier errors).
This also means we remote the stop_on_first_error argument
from flatpak_transaction_run() as this is now controlled by
the caller.
This moves all the files from lib into common, and it also adds all the libflatpak
sources into libflatpak-common, making libflatpak just a wrapper around the common
helper library.
This move allows the CLI to use all the code from libflatpak. We were already doing
this with a few things like flatpak-error*.[ch], and we want to do it even more
when sharing FlatpakTransaction. This also allows use to slowly move
the CLI to using the libflatpak apis for some things.
Closes: #1706
Approved by: alexlarsson
