Instead of resolving dependencies when adding refs to the list we make
adding refs trivial, and then add a dependency-resolving and ordering
phase to the start of flatpak_transaction_run().
Instead of resolving dependencies for each ref by itself this means
that we have a long list of refs we can work on. For the moment this
isn't really used, but it will later allow us to be much more
efficient in the p2p codepath because we can hand over a lot of refs
in a single p2p operation.
There are some complexities, for instance, we don't know initially
which the final refs will be, because the dependency resolving will
add new ones, yet we must still start with some operation.
The way this works is by repeated stages:
* Resolve the operatations for all the initially specified
refs. Resolve means doing i/o to determine the latest available
commit id, and the corresponding metadata for that commit.
* Add dependencies for all resolved ops, this typically means looking
at the apps and finding which runtime they need, and then finding a
runtime to install or update.
* Resolve all new refs, meaning we now load the metadata for the
runtime dependencies we added before.
* Add related refs for all resolved ops, i.e. extensions for apps
and runtimes. These are marked for install/update as needed.
* Resolve the final refs.
Now we have a full list of things that we need to install or update,
and for each the commit id and the corresponding metadata. We can at
this point:
* Verify that the metadata is valid for this version of flatpak
* Verify that the metadata permissions are not greater than the
previous version on updates (confirm if so).
* Guarantee that the above verification will be correct becase
we resolved each operation to a particular commit it that we
will pull.
* Quickly decide which update operations to skip because they
are no-ops (same as installed version).
There are also some complexities wrt operation ordering. Previously
we decided the ordering when emitting the dependencies, but now
we can't do that since the dependencies are added in non-ordered chunks.
Instead we add some dependency information during the dependency
gathering and do a topological sort at the end.
This is the first step towards a better transaction handling, but here
are still some things left to do:
* resolve_ops() calls flatpak_dir_find_latest_rev() for each
operation, which is fine in the normal case as it just looks
at the summary cached in the RemoteState. However in the p2p
case it is very inefficient. Now that we have a chunk of
refs we could resolve in parallel we should instead do a
single find_remotes() + pull_remotes(COMMITS_ONLY) operation which
will be much faster.
* In the p2p case we're still using the metadata from the ostree-metadata
branch, which may not be the same as the version we will actually be
pulling. The above COMMITS_ONLY pull operation will allow us to instead
read the metadata from the real commit objects (which we're guaranteed
to actually get due to us locking down the commit id when pulling).
* Even in the non-p2p case we get the wrong metadata when doing an
explicit downgrade (update --commit=...) because we're using the
metadata from the summary which only applies to the latest commit.
This needs to be changed to also pull the commit object.
* After resolve, but before pulling the full ref we are not currently
doing metadata permission verification (vs last installed version)
to see if new permissions need to be requested. This needs to be
added. We could also let the user pass in pre-acked permissions so
that a UI can show permissions ahead of time and then avoid
confirming them again.
Closes: #1787
Approved by: alexlarsson
These are split into two, one that loads the metadata and one
that works on the pre-loaded GKeyFile.
This changes no behaviour, but we will later use the split out
functions from FlatpakTransaction when we already have the
metadata loaded.
Closes: #1787
Approved by: alexlarsson
This splits out the part that extracts the current commit id
from the code that sees if given a particular commit id we need
to update.
Closes: #1787
Approved by: alexlarsson
p11-kit server version < 0.23.10 doesn't properly daemonize which
causes g_spawn_sync() to hang forever waiting for the pipe to
close.
We work around this by passing --sh, which is only available in the
working version, and fill fail the old ones.
https://github.com/flatpak/flatpak/issues/1768Closes: #1782
Approved by: alexlarsson
No portal is currently using broadcasts, but we want to eventually use
them in dconf. But when doing that they can't be sent to all instances
but rather limited by the sender (dconfd). The exact way this will work
is still unclear, but to pave the way for this we start by defaulting
to not delivering any broadcasts.
Closes: #1689
Approved by: alexlarsson
Each flatpak instance gets a (random uint32) identifier which is
unique during the runtime of the instance. Additionally there is a
directory created in $XDR_RUN_DIR/.flatpak/$id which is writable on
the host, but read-only bind-mounted into the sandbox. Services (like
dconf which this targets) can use this to pass file data to the
sandbox instance.
We use locks on a file in the instance directory to ensure that we
can clean up unused directories.
The container id is also put in the .flatpak-info file so that
portals can know where the instance directory is.
Closes: #1689
Approved by: alexlarsson
Some apps (like libreoffice) has multiple sup-apps, so we allow them to have multiple
appstream components (as well as e.g. multiple desktop files).
Fixes#1749Closes: #1778
Approved by: alexlarsson
If there was no refs found to delete, we don't want to print the "ok?" prompt.
Instead we just say that nothing was found.
Closes: #1776
Approved by: alexlarsson
When under load (for example running parallel tests) it can take a
while to get the web server ready.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #1760
Approved by: alexlarsson
This always printed "setting HOME=(null)" because we didn't set
datadir yet, but it should have been looking at homedir anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #1760
Approved by: alexlarsson
If p11-kit server is installed on the host, we spawn a copy of this, forwarding the access to the
p11-kit trust module in a read-only way.
We then (if the above worked) bind mount the socket as /run/user/$UID/p11-kit/pkcs11 in the sandbox,
which is the default socket path for the p11-kit-client module.
We also add a configuration file in /etc/pkcs11/modules/p11-kit-trust.module that makes the trust
module actually load the client module instead. This means applications automatically switch
to using the host certs for trust if possible, and use the runtime ca-certificates otherwise.
Additionally we add a config file that always disables pkcs user
config merging, because pkcs11 modules on the host are unlikely to work in a random runtime.
Closes: #1757
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
Simplify some of the return logic when handling pushing/popping the
thread default main context by using g_autoptr(GMainContextPopDefault).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1736
Approved by: alexlarsson
The idea is for e.g. the gl extension to have
download-if=active-gl-driver
autoprune-unless=active-gl-driver
And then we can automatically find and uninstall unused gl drivers.
Closes: #1754
Approved by: alexlarsson
We were not correctly handling the partial refs that ostree_repo_list_refs()
returned, instead assuming they were full refs.
Closes: #1754
Approved by: alexlarsson
This moves the triggers from out of flatpak_install/update/uninstall
and instead calls them manually at all the sites that call this.
This allows FlatpakTransaction to only run the triggers once for the
entire operation.
Closes: #1743
Approved by: alexlarsson
