This will be useful in gnome-software's flatpak plugin, which currently
iterates over the operations a few times, and it will be useful
internally as well.
This makes it a lot easier to give guidance on using `flatpak run -d` or
`flatpak-coredumpctl`, because there's an easy way to install the
relevant refs.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
This complements `flatpak_transaction_set_no_interaction()` and allows
calling code to see if a given transaction is interactive.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This returns the actual subpath that will be fetched during the operation,
not just what was passed in.
NOTE: We were previously doing the final resolve of this in the update
case during the pull operation, but this commit changes that to do it
up-front in order to be able to return the right value for this.
This is similar to the ready signal, except it is called before
per-ref authentication. Apps can use this if they want to be able
to ask for user input on progress before asking for authentication.
This is nice to be able to do in general, but it is also required for
the implementation of
flatpak_installation_list_installed_refs_for_update(), as it doesn't
install any authentication handler, so it will never report updates
for protected refs if using the ready signal.
Note: In special cases we will require authentication even earlier
if authenticating is needed during the resolve operation. This happens
for instance if you are doing a update to a particular commit (rather
than the lastest commit) where we need to get the commit object directly.
In case a runtime becomes unused and then later becomes End-Of-Life, it
is currently not removed. So this commit removes such runtimes in the
update command, as discussed in #2639. A unit test is included.
I am planning to propose to use the FlatpakTransaction API added here in
gnome-software, so that users don't have to use the CLI at all for
runtimes to be cleaned up. KDE Discover already removes unused runtimes
periodically.
If a transaction requires to install an authenticator before it can
continue this signal will be emitted, allowing you to create a new
transaction to install the required authenticator.
This is useful if to avoid changing the no-interaction of the whole
FlatpakInstallation. Also, having this per transaction lets us
clean up the code in FlatpakQuietTransaction a bit.
This exposes the `skip` member of `FlatpakTransactionOperation`, as it’s
needed for callers to usefully traverse the operation graph (which is
now accessible using
`flatpak_transaction_operation_get_related_to_op()`).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This will be used in the following commit, so we can track what
installed thing needs an update when there's a transaction operation to
e.g. install its missing runtime or extension.
This adds a new way for authenticators to trigger interactive authentication
in the client for simple user/password dialogs. These are not recommended
to use as a webflow is often better. However, for OCI remotes that
use http basic auth this is useful and allows the CLI experience to work
with that.
An event happens more often as its frequency gets higher, so these
values were confusing me.
Rename the constants to include their unit (ms) as well, to avoid
confusion.
Anything that affects public API (such as
flatpak_transaction_progress_set_update_frequency()) or libostree's
options passed to ostree_repo_pull_with_options(), is left as is.
This allows the authenticator to directly do UI and parent it to the
relevant window. The actual parent string is specified just like
the xdg-desktop-portal one.
There is a new flatpak_transaction_set_parent_window() function that
clients can use to signal the what window they want to be parented to.
These signals are emitted when the authenticator needs some kind of
web-based authentication. If the caller implements webflow-start and
returns TRUE, then it needs to show the user the URL and allow the user
to interact with it.
Typically this ends with the web-page being redirected to a url to
localhost or similar which tells the authenticator the result of the
operations. This will cause the webflow-done signal to be emitted and
the transaction operation to continue. If something goes wrong (or the
signal is not handled) it will also report webflow-done, but then the
transaction will fail in a normal way.
Generally all users of FlatpakTransaction need to do is:
On webflow-start, show a browser window with the url and return TRUE.
On webflow-done, close the browser window if its still visible.
If the user closes the browser window early, call
flatpak_transaction_abort_webflow().
FlatpakTransaction inherently doesn't differentiate between a
autoupdate and a regular update; both are
FLATPAK_TRANSACTION_OPERATION_UPDATE.
This getter can help differentiate between a regular update
and autoupdate in clients like gnome-software. Autoupdates
work in two separate transaction passes; first that runs with
"no-deploy" and the second pass that deploys all the downloaded
update (i.e. with "no-pull").
This restores the ABI to the pre-1.4.0 version. This moves the new signal to
the *end* of the struct and also correctly decrements the padding.
Fixes https://github.com/flatpak/flatpak/issues/2957, although we probably need
a 1.4.1 release with this included pretty quickly to avoid chaos.
Closes: #2958
Approved by: alexlarsson
end-of-lifed-with-rebase runs earlier in the transaction system than end-of-lifed, meaning it can modify the transaction for rebasing.
The new flatpak_transaction_add_rebase() function can then be used to apply the rebase if wanted.
Closes: #2775
Approved by: alexlarsson
Add a function to FlatpakTransactionProgress to get the
number of transferred bytes. This is useful information
to show during a long-running download.
Closes: #2371
Approved by: alexlarsson
Add api to get the download and installed size
of resolved operations. This is useful information
to present to the user before running the transaction.
Closes: #2371
Approved by: alexlarsson
We were emitting the ::operation-done signal with
different arguments than declared for the signal.
This showed up as test failure when comparing
the result argument.
Closes: #2187
Approved by: alexlarsson
This adds the flatpak_transaction_add_install_flatpakref method
to easily install from flatpakref files. It additionally
adds a new signal called add-new-remote which is called in two
cases:
To ask if the user wants to add a "normal" remote for the url
specified by a flatpakref file.
When a new remote is required for the runtimes the application
depends on.
Closes: #1868
Approved by: alexlarsson
This will be used as the default when installing something that
doesn't specify a ref, such as a flatpakref file.
Closes: #1868
Approved by: alexlarsson
This changes the signals to use a FlatpakTransactionOperation
argument instead of a bunch of arguments in the signal, making
this easier to extend in the future.
This is an API break, but nobody is using this API yet, and it
was only available in one unstable release.
Closes: #1797
Approved by: alexlarsson
This signal is emitted after all the added operations and their dependencies
are resolved and we have the full list of things that will be
done as part of the transaction. At this point you can call
flatpak_transaction_get_operations() and decide if you want to
continue with the operation.
Closes: #1797
Approved by: alexlarsson
Instead use FlatpakTransactionOperationType internally too,
but extend it with a INSTALL_OR_UPDATE value which is not public.
Closes: #1797
Approved by: alexlarsson
In the no-pull case and when uninstalling, we never want to do any network
i/o for e.g. detecting depenedencies.
Closes: #1744
Approved by: alexlarsson
