This allows us to resolve as many operations as possible in parallel
which is much faster than doing the p2p queries for each potential
update.
Fixes#1592Closes: #1796
Approved by: alexlarsson
This takes a list of refs + remotes and optional commit, all
which need to be p2p (i.e. have collection-id != NULL) refs, and
uses the p2p API to resolve the refs to the latest available commit
it and the matching metadata for that version.
It does this by doing a find_remotes() and then a pull_from_remotes
with PULL_FLAG_COMMIT_ONLY and then extracting the metadata
from the commit object.
We also do some checking before pulling so that if we have the latest
reported commit already available locally then we don't pull anything
for that ref (instead resolving to the locally available metadata).
We always pull to a child repo so that we have write-rights even as a
user (in the system case) and so we can properly clean up the temporary
results.
Note, this unconditionally uses the p2p APIs, and it relies on the latest
ostree master which has a fix that allows us to read the latest refs from
the transaction.
Closes: #1796
Approved by: alexlarsson
There is no need to force a fsync after pulling into the child repo,
because we will anyway copy/verify it into the system repo. It is
never used for stable storage.
This makes system installation faster.
Closes: #1808
Approved by: alexlarsson
This commit removes fetches of ostree-metadata from
flatpak_dir_install() and flatpak_dir_update(), which both pull it into
the child repo when doing system-helper deployments. Both functions have
a FlatpakRemoteState object passed in and when that is initialized,
_flatpak_dir_fetch_remote_state_metadata_branch() pulls and deploys
ostree-metadata so it can be queried against for repo metadata and
served onto LAN and USB peers. So there's no need to pull it again here.
The issue of resolving a ref and its metadata atomically remains, but
that will be addressed by https://github.com/flatpak/flatpak/pull/1796.
Closes: #1806
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
SSH authentication sockets can be placed in a number of places, so it
is difficult for applications to just mount a fixed directory or
directories, hoping that SSH_AUTH_SOCK points somewhere inside the
mounted content.
Closes: #1764
Approved by: alexlarsson
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
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 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
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
This does no network i/o and just keeps track of remote name
and collection id. This can be used for no-pull transactions.
Closes: #1744
Approved by: alexlarsson
This reads the current commit for a ref in the local repo.
This can be used e.g. to get at the metadata for an already pulled ref.
Closes: #1744
Approved by: alexlarsson
This is the same as flatpak_dir_search_for_dependency, but it looks only in the local
repo for already pulled dependencies. This is useful if you're in no-pull mode.
Closes: #1744
Approved by: alexlarsson
This makes info, list, remotes, and search work if there is no
system flatpak repo. Before it failed with EPERM.
Closes: #1742
Approved by: alexlarsson
