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 is a pretty lowlevel version of the permissions, and there
is no nice API for the library to produce these. However its got
the basics of permission tracking.
Closes: #1799
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
I generated this list mechanically from the big if () condition in
flatpak-builtins-info.c, which is why they're one per line, and I think
it's more maintainable in this layout. (Whitespace has no effect on the
HTML or manpage output.)
Closes: #1788
Approved by: alexlarsson
Compared to `flatpak info --help` (which is what actually counts), 6
options were not documented, and one (--version) was documented but
doesn't exist.
Closes: #1788
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
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
