This is an object that contains the state of a particular remote
at a point in time, such as the summary and the metadata. Storing
this in an object means we can reuse these data instead of constantly
looking them up.
This is more efficient, but also avoids possible inconsistencies if
the state changes during an operation.
There is also an "optional" mode for the state where we don't fail in
the p2p/collection-id case if it fails to load the summary or metadata.
This is useful in order to support certain operations "offline" (i.e.
with no network connection to the main repo).
Closes: #1575
Approved by: alexlarsson
Before, we would list a ref as installed if the directory for the
ref was in the installation. However, if that was empty then we
would still consider that as installed. We also now require
there to be an active symlink with a deploy file in it.
This caused issues for me on update, because we listed some app
as installed, but then failed to update it.
Closes: #1573
Approved by: alexlarsson
The GFileMonitor returned by flatpak_installation_create_monitor() is
already tested in test_install_launch_uninstall(), so there's not much
point in testing it again in test_list_updates, and for some reason it
is causing a test failure on OBS.
Closes: #1567
Approved by: alexlarsson
Until recently, "flatpak update --appstream" caused flatpak to only
update appstream data. Then commit 20c842012 accidentally made flatpak
also do a full update after updating appstream data, so this commit
fixes the regression.
Closes: #1571
Approved by: alexlarsson
This is a minimum viable implementation that just prints a warning.
A more comprehensive handling is possible, especially wrt the
rebase case.
Closes: #1566
Approved by: alexlarsson
This adds a "sparse-cache" metadata dict to the summary, where
we can add additional per-ref information that we don't expect
to be there for most refs. Initially we add the eol and
eol-rebase info to it so that we can see which remote refs
are end-of-line.
Closes: #1566
Approved by: alexlarsson
The flatpak-uninstall command now automatically chooses which
installation to use, so document that in the man page, and fix a few
other minor mistakes.
Closes: #1558
Approved by: alexlarsson
Currently flatpak_insallation_list_installed_refs_for_update() only
checks the configured remotes for updates. This means that updates from
peer sources such as USB drives or computers on the LAN are never seen,
which is especially problematic when the computer is offline. The end
result is that GNOME Software doesn't show an "Update" button to let you
update an app from a USB drive when you're offline.
This commit uses ostree API, primarily ostree_repo_find_remotes_async(),
to check peer sources for updates from any remotes that have a
collection ID configured. We're using an ostree 2018.5 feature from
https://github.com/ostreedev/ostree/pull/1518, but I used a version
check for that (it hasn't been released yet). Without it you can't tell
if an offered commit is an update or a downgrade, but that behavior is
still better than the status quo (no updates from P2P sources at all).
Closes: #1542
Approved by: alexlarsson
Use a collection ID on the test repo if P2P support is enabled. This
will allow for testing of more API that makes use of collection IDs.
Closes: #1542
Approved by: alexlarsson
This way we never get confused about which part of the argument
is the permission suffix, which could be exploitable if you can
control the --filesystem calls such as with sandboxed Spawns.
This listens to org.freedesktop.portal.Flatpak and lets flatpak
sandboxes do flatpak specific things.
Initially this only allows access to "Spawn", which lets you start a
new copy of the current or latest version of the calling app,
optionally with sandboxing.
This allows the app to re-start itself with the latest version after
an update, and the sandboxing is useful for apps that want to manually
sandbox part of themselves.
You can also expose one or more subdirectories of
~/.var/app/$appid/sandbox/ to the app, read-write or read-only. This is
useful to communicate with the sandbox.
This runs the app in a very tight sandbox, with no access to anything
except /app and /run and some read-only host things like fonts and icons.
You can additionally add explicit permissions on the commandline,
like --share=network to actually grant some access.
This also sets $FLATPAK_SANDBOX_DIR to ~/.var/app/$appid/sandbox in the
environment.
This means if we undeploy something, but its still in use, then
we can find it later. This is interesting because it lets
us re-find it for spawning an instance of the same version.
So, if you run your instance with e.g. flatpak run --filesystem=/some/dir
you can now see this. This will be useful in the restart yourself
portal as we can then inherit such permissions.
When uninstalling, if no specific installation was specified with e.g.
--user or --system, automatically chose any unique match, or error
out if there are multiple alternatives.
Fixes#1321
