Top |
FlatpakInstallation * | installation | Read / Write / Construct Only |
gboolean | no-interaction | Read / Write |
FlatpakTransaction is an object representing an install/update/uninstall
transaction. You create an object like this using flatpak_transaction_new_for_installation()
and then you add all the operations (installs, updates, etc) you wish to do. Then
you start the transaction with flatpak_transaction_run()
which will resolve all kinds
of dependencies and report progress and status while downloading and installing these.
The dependency resolution that is the first step of executing a transaction can
be influenced by flatpak_transaction_set_disable_dependencies()
,
flatpak_transaction_set_disable_related()
, flatpak_transaction_add_dependency_source()
and flatpak_transaction_add_default_dependency_sources()
.
The underlying operations that get orchestrated by a FlatpakTransaction are: pulling
new data from remote repositories, deploying newer applications or runtimes and pruning
old deployments. Which of these operations are carried out can be controlled with
flatpak_transaction_set_no_pull()
, flatpak_transaction_set_no_deploy()
and
flatpak_transaction_set_disable_prune()
.
A transaction is a blocking operation, and all signals are emitted in the same thread. This means you should either handle the signals directly (say, by doing blocking console interaction, or by just returning without interaction), or run the operation in a separate thread and do your own forwarding to the GUI thread.
Despite the name, a FlatpakTransaction is more like a batch operation than a transaction in the database sense. Individual operations are carried out sequentially, and are atomic. They become visible to the system as they are completed. When an error occurs, already completed operations are not rolled back.
For each operation that is executed during a transaction, you first get a “new-operation” signal, followed by either a “operation-done” or “operation-error”.
The FlatpakTransaction API is threadsafe in the sense that it is safe to run two transactions at the same time, in different threads (or processes).
Note: Transactions (or any other install/update operation) to a system installation rely on the ability to create files that are readable by other users. Some users set a umask that prohibits this. Unfortunately there is no good way to work around this in a threadsafe, local way, so such setups will break by default. The flatpak commandline app works around this by calling umask(022) in the early setup, and it is recommended that other apps using libflatpak do this too.
FlatpakTransaction * flatpak_transaction_new_for_installation (FlatpakInstallation *installation
,GCancellable *cancellable
,GError **error
);
Creates a new FlatpakTransaction object that can be used to do installation
and updates of multiple refs, as well as their dependencies, in a single
operation. Set the options you want on the transaction and add the
refs you want to install/update, then start the transaction with
flatpak_transaction_run()
.
gboolean flatpak_transaction_add_install (FlatpakTransaction *self
,const char *remote
,const char *ref
,const char **subpaths
,GError **error
);
Adds installing the given ref to this transaction.
The remote
can either be a configured remote of the installation,
or a file:// uri pointing at a local repository to install from,
in which case an origin remote is created.
gboolean flatpak_transaction_add_install_bundle (FlatpakTransaction *self
,GFile *file
,GBytes *gpg_data
,GError **error
);
Adds installing the given bundle to this transaction.
gboolean flatpak_transaction_add_install_flatpakref (FlatpakTransaction *self
,GBytes *flatpakref_data
,GError **error
);
Adds installing the given flatpakref to this transaction.
gboolean flatpak_transaction_add_rebase (FlatpakTransaction *self
,const char *remote
,const char *ref
,const char **subpaths
,const char **previous_ids
,GError **error
);
Adds updating the previous_ids
of the given ref to this transaction, via either
installing the ref
if it was not already present or updating it. This will
treat ref
as the result of following an eol-rebase, and data migration from
the refs in previous_ids
will be set up.
See flatpak_transaction_add_install()
for a description of remote
.
self |
||
remote |
the name of the remote |
|
ref |
the ref |
|
subpaths |
the subpaths to include, or |
[nullable] |
previous_ids |
Previous ids to add to the given ref. These should simply be the ids, not the full ref names (e.g. org.foo.Bar, not org.foo.Bar/x86_64/master). |
[nullable][array zero-terminated=1] |
error |
return location for a GError |
Since: 1.3.3.
gboolean flatpak_transaction_add_update (FlatpakTransaction *self
,const char *ref
,const char **subpaths
,const char *commit
,GError **error
);
Adds updating the given ref to this transaction.
self |
||
ref |
the ref |
|
subpaths |
subpaths to install; |
[nullable][array zero-terminated=1] |
commit |
the commit to update to, or |
[nullable] |
error |
return location for a GError |
gboolean flatpak_transaction_add_uninstall (FlatpakTransaction *self
,const char *ref
,GError **error
);
Adds uninstalling the given ref to this transaction. If the transaction is set to not deploy updates, the request is ignored.
void
flatpak_transaction_add_default_dependency_sources
(FlatpakTransaction *self
);
Similar to flatpak_transaction_add_dependency_source()
, but adds
all the default installations, which means all the defined system-wide
(but not per-user) installations.
void flatpak_transaction_add_dependency_source (FlatpakTransaction *self
,FlatpakInstallation *installation
);
Adds an extra installation as a source for application dependencies. This means that applications can be installed in this transaction relying on runtimes from this additional installation (whereas it would normally install required runtimes that are not installed in the installation the transaction works on).
Also see flatpak_transaction_add_default_dependency_sources()
.
gboolean flatpak_transaction_run (FlatpakTransaction *transaction
,GCancellable *cancellable
,GError **error
);
Executes the transaction.
During the course of the execution, various signals will get emitted. The FlatpakTransaction::choose-remote-for-ref and “add-new-remote” signals may get emitted while resolving operations. “ready” is emitted when the transaction has been fully resolved, and “new-operation” and “operation-done” are emitted while the operations are carried out. If an error occurs at any point during the execution, “operation-error” is emitted.
Note that this call blocks until the transaction is done.
FlatpakTransactionOperation *
flatpak_transaction_get_current_operation
(FlatpakTransaction *self
);
Gets the current operation.
FlatpakInstallation *
flatpak_transaction_get_installation (FlatpakTransaction *self
);
Gets the installation this transaction was created for.
GList *
flatpak_transaction_get_operations (FlatpakTransaction *self
);
Gets the list of operations. Skipped operations are not included. The order of the list is the order in which the operations are executed.
gboolean
flatpak_transaction_is_empty (FlatpakTransaction *self
);
Returns whether the transaction contains any non-skipped operations.
void flatpak_transaction_set_disable_dependencies (FlatpakTransaction *self
,gboolean disable_dependencies
);
Sets whether the transaction should ignore runtime dependencies when resolving operations for applications.
void flatpak_transaction_set_disable_prune (FlatpakTransaction *self
,gboolean disable_prune
);
Sets whether the transaction should avoid pruning the local OSTree repository after updating.
void flatpak_transaction_set_disable_related (FlatpakTransaction *self
,gboolean disable_related
);
Sets whether the transaction should avoid adding related refs when resolving operations. Related refs are extensions that are suggested by apps, such as locales.
void flatpak_transaction_set_disable_static_deltas (FlatpakTransaction *self
,gboolean disable_static_deltas
);
Sets whether the transaction should avoid using static deltas when pulling.
void flatpak_transaction_set_no_deploy (FlatpakTransaction *self
,gboolean no_deploy
);
Sets whether the transaction should download updates, but not deploy them.
gboolean
flatpak_transaction_get_no_deploy (FlatpakTransaction *self
);
Gets whether the transaction is only downloading updates, and not deploying them.
Since: 1.5.1
void flatpak_transaction_set_no_pull (FlatpakTransaction *self
,gboolean no_pull
);
Sets whether the transaction should operate only on locally available data.
gboolean
flatpak_transaction_get_no_pull (FlatpakTransaction *self
);
Gets whether the transaction should operate only on locally available data.
Since: 1.5.1
void flatpak_transaction_set_reinstall (FlatpakTransaction *self
,gboolean reinstall
);
Sets whether the transaction should uninstall first if a ref is already installed.
void flatpak_transaction_set_force_uninstall (FlatpakTransaction *self
,gboolean force_uninstall
);
Sets whether the transaction should uninstall files even if they're used by a running application.
void flatpak_transaction_set_default_arch (FlatpakTransaction *self
,const char *arch
);
Sets the architecture to default to where it is unspecified.
void flatpak_transaction_set_parent_window (FlatpakTransaction *self
,const char *parent_window
);
Sets the parent window (if any) to use for any UI show by this transaction. This is used by authenticators if they need to interact with the user during authentication.
The format of this string depends on the display system in use, and is the same as used by xdg-desktop-portal.
On X11 it should be of the form x11:$xid where $xid is the hex version of the xwindows id.
On wayland is should be wayland:$handle where handle is gotten by using the export call of the xdg-foreign-unstable wayland extension.
Since: 1.5.1
const char *
flatpak_transaction_get_parent_window (FlatpakTransaction *self
);
Gets the parent window set for this transaction, or NULL
if unset. See
flatpak_transaction_get_parent_window()
.
Since: 1.5.1
void flatpak_transaction_abort_webflow (FlatpakTransaction *self
,guint id
);
Cancel an ongoing webflow authentication request. This can be call
in the time between “webflow-start” returned
TRUE
, and “webflow-done” is emitted. It will
cancel the ongoing authentication operation.
This is useful for example if you're showing an authenticaion window with a browser, but the user closed it before it was finished.
Since: 1.5.1
The type of a FlatpakTransactionOperation.
“installation”
property“installation” FlatpakInstallation *
The installation that the transaction operates on.
Owner: FlatpakTransaction
Flags: Read / Write / Construct Only
“add-new-remote”
signalgboolean user_function (FlatpakTransaction *object, int reason, char *from_id, char *suggested_remote_name, char *url, gpointer user_data)
The ::add-new-remote signal gets emitted if, as part of the transaction,
it is required or recommended that a new remote is added, for the reason
described in reason
.
object |
||
reason |
A FlatpakTransactionRemoteReason for this suggestion. |
[type FlatpakTransactionRemoteReason] |
from_id |
The id of the app/runtime |
|
suggested_remote_name |
The suggested remote name |
|
url |
The repo url |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run Last
“basic-auth-start”
signalgboolean user_function (FlatpakTransaction *object, char *remote, char *realm, GVariant *options, int id, gpointer user_data)
The ::basic-auth-start signal gets emitted when a basic user/password
authentication is needed during the operation. If the caller handles this
it should ask the user for the user and password and return TRUE
. Once
the information is gathered call flatpak_transaction_complete_basic_auth()
with it.
If the client does not support basic auth then return FALSE
from this signal
(or don't implement it). This will abort the authentication and likely
result in the transaction failing (unless the authentication was somehow
optional).
object |
||
remote |
The remote we're authenticating with |
|
realm |
The url to show |
|
options |
Extra options, currently unused |
|
id |
The id of the operation, can be used to finish it |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run Last
Since: 1.5.2
“choose-remote-for-ref”
signalint user_function (FlatpakTransaction *object, char *for_ref, char *runtime_ref, GStrv remotes, gpointer user_data)
The ::choose-remote-for-ref signal gets emitted when a remote needs to be selected during the execution of the transaction.
object |
||
for_ref |
The ref we are installing |
|
runtime_ref |
The ref we are looking for |
|
remotes |
the remotes that has the ref, sorted in prio order |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run Last
“end-of-lifed”
signalvoid user_function (FlatpakTransaction *object, char *ref, char *reason, char *rebase, gpointer user_data)
The ::end-of-lifed signal gets emitted when a ref is found to be marked as end-of-life during the execution of the transaction.
Flags: Run Last
“end-of-lifed-with-rebase”
signalgboolean user_function (FlatpakTransaction *object, char *remote, char *ref, char *reason, char *rebased_to_ref, GStrv previous_ids, gpointer user_data)
The ::end-of-lifed-with-rebase signal gets emitted when a ref is found to be marked as end-of-life before the transaction begins. Unlike “end-of-lifed”, this signal allows for the transaction to be modified in order to e.g. install the rebased ref.
If the caller wants to install the rebased ref, they should call
flatpak_transaction_add_uninstall()
on ref
,
flatpak_transaction_add_rebase()
on rebased_to_ref
, and return TRUE
.
Otherwise FALSE
may be returned.
object |
||
remote |
The remote for the ref we are processing |
|
ref |
The ref we are processing |
|
reason |
The eol reason, or |
|
rebased_to_ref |
The new name, if rebased, or |
|
previous_ids |
The previous names for the rebased ref (if any), including the one from |
|
user_data |
user data set when the signal handler was connected. |
TRUE
if the operation on this end-of-lifed ref should
be skipped (e.g. because the rebased ref has been added to the
transaction), FALSE
if it should remain.
Flags: Run Last
Since: 1.3.2
“install-authenticator”
signalvoid user_function (FlatpakTransaction *object, char *remote, char *authenticator_ref, gpointer user_data)
The ::install-authenticator signal gets emitted if, as part of resolving the transaction, we need to use an authenticator, but the authentication is not installed, but is available to be installed from the ref.
The application can handle this signal, and if so create another transaction to install the authenticator.
The default handler does nothing, and if the authenticator is not installed when the signal handler fails the transaction will error out.
object |
||
remote |
The remote name |
|
authenticator_ref |
The ref for the authenticator |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run Last
Since: 1.8.0
“new-operation”
signalvoid user_function (FlatpakTransaction *object, FlatpakTransactionOperation *operation, FlatpakTransactionProgress *progress, gpointer user_data)
The ::new-operation signal gets emitted during the execution of the transaction when a new operation is beginning.
object |
||
operation |
The new FlatpakTransactionOperation |
|
progress |
A FlatpakTransactionProgress for |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run Last
“operation-done”
signalvoid user_function (FlatpakTransaction *object, FlatpakTransactionOperation *operation, char *commit, int result, gpointer user_data)
The ::operation-done signal gets emitted during the execution of the transaction when an operation is finished.
object |
||
operation |
The FlatpakTransactionOperation which finished |
|
commit |
The commit. |
[nullable] |
result |
A FlatpakTransactionResult giving details about the result. |
[type FlatpakTransactionResult] |
user_data |
user data set when the signal handler was connected. |
Flags: Run Last
“operation-error”
signalgboolean user_function (FlatpakTransaction *object, FlatpakTransactionOperation *operation, GError *error, int details, gpointer user_data)
The ::operation-error signal gets emitted when an error occurs during the execution of the transaction.
object |
||
operation |
The FlatpakTransactionOperation which failed |
|
error |
A GError |
|
details |
A FlatpakTransactionErrorDetails with details about the error. |
[type FlatpakTransactionErrorDetails] |
user_data |
user data set when the signal handler was connected. |
Flags: Run Last
“ready”
signalgboolean user_function (FlatpakTransaction *object, gpointer user_data)
The ::ready signal is emitted when all the refs involved in the operation
have been resolved to commits, and the required authentication for all ops is gotten.
At this point flatpak_transaction_get_operations()
will return all the operations
that will be executed as part of the transaction.
Flags: Run Last
“ready-pre-auth”
signalgboolean user_function (FlatpakTransaction *object, gpointer user_data)
The ::ready-pre-auth signal is emitted when all the refs involved in the transaction have been resolved to commits, but we might not necessarily have asked for authentication for all their required operations. This is very similar to the ::ready signal, and you can choose which one (or both) to use depending on how you want to handle authentication in your user interface.
At this point flatpak_transaction_get_operations()
will return all the
operations that will be executed as part of the transaction. You can call
flatpak_transaction_operation_get_requires_authentication()
to see which
will require authentication.
Flags: Run Last
Since: 1.9.1
“webflow-done”
signalvoid user_function (FlatpakTransaction *object, GVariant *options, int id, gpointer user_data)
The ::webflow-done signal gets emitted when the authentication finished the webflow, independent of the reason and results. If you for were showing a web-browser window it can now be closed.
object |
||
options |
Extra options, currently unused |
|
id |
The id of the operation |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run Last
Since: 1.5.1
“webflow-start”
signalgboolean user_function (FlatpakTransaction *object, char *remote, char *url, GVariant *options, int id, gpointer user_data)
The ::webflow-start signal gets emitted when some kind of user
authentication is needed during the operation. If the caller handles this
it should show the url in a webbrowser and return TRUE
. This will
eventually cause the webbrowser to finish the authentication operation and
operation will continue, as signaled by the webflow-done being emitted.
If the client does not support webflow then return FALSE
from this signal
(or don't implement it). This will abort the authentication and likely
result in the transaction failing (unless the authentication was somehow
optional).
During the time between webflow-start and webflow-done the client can call
flatpak_transaction_abort_webflow()
to manually abort the authentication.
This is useful if the user aborted the authentication operation some way,
like e.g. closing the browser window.
object |
||
remote |
The remote we're authenticating with |
|
url |
The url to show |
|
options |
Extra options, currently unused |
|
id |
The id of the operation, can be used to cancel it |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run Last
Since: 1.5.1