When listing refs installed or from a remote, only the refs matching the
main collection-id were being returned. However, it is very important to
have access to all refs, independently from their collection-id,
especially when trying to list remotes coming from a USB repository.
These changes add the mentioned refs and update the places that use
this list, both in the lib and in the CLI.
For the implementation to become easier, we introduce also a
FlatpakCollectionRef, that should be replaced by OstreeCollectionRef
once the latter becomes part of the general API (currently it is in the
experimental one).
Closes: #1587
Approved by: mwleeds
Since we can now get the URL of the remote directly from the
OstreeRemote object, we should use it when creating a FlatpakRemote.
This will allow temporary FlatpakRemote objects (corresponding to
removable mounts) to have a URL set to them.
Closes: #1587
Approved by: mwleeds
This adds things like the size and the metadata, as well as eol strings
to FlatpakRemoteRef. We typically have this accessible anyway, in the
FlatpakRemoteState.
This makes flatpak_installation_fetch_remote_size/metadata_sync deprecated.
Closes: #1591
Approved by: alexlarsson
To implement this, we have a concept of a custom export filter
function which can be specified for each path to determine the
files that can be exported under that path.
Closes: #1589
Approved by: alexlarsson
We will use this later to work out which .service files we can export
based on names that we are allowed to own.
Closes: #1589
Approved by: alexlarsson
This moves the prune call out of flatpak_dir_update() and
flatpak_dir_uninstall() and instead does this manually at all call
sites. The advantage is that we now only call it *once* even if you
uninstall or update multiple apps.
This means update everything is much faster as we don't have to scan
over the entire local repo for each updated app.
A desktop file can specify this key to add additional arguments
to flatpak run. Right now, only 'no-a11y-bus' is supported.
Closes: #1579
Approved by: alexlarsson
_flatpak_dir_fetch_remote_state_metadata_branch is only used when building
with p2p, so #ifdef the entire function.
Closes: #1575
Approved by: alexlarsson
Reusing the summary and metadata here helps us a lot as typically we
often want to look up the cache data again for every ref in the list.
Closes: #1575
Approved by: alexlarsson
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
