Since we have several types of remotes, it is important to have the
option of choosing which types one wants when listing them because
depending on the type it may have an impact in the performance (e.g.
when listing LAN remotes).
For that reason this patch adds a new method
"flatpak_installation_list_remotes_by_type" that allows to specify
which types of remotes should be returned. When giving an empty array
of types, it means that all types should be returned instead, which can
be more useful than actually asserting or not doing anything.
Closes: #1587
Approved by: mwleeds
When listing refs from remotes, a remote can be given by name or by URI.
This is an important distinction because dynamic remotes (USB/LAN) are
not internally mapped to a name, and thus their generated name cannot be
used for listing them. Thus, the solution is to use their URI in order
to list the refs directly from it.
Even though this feature has been around forever, the documentation
didn't really reflect it, so this patch mentions the described
alternative possibility.
Closes: #1587
Approved by: mwleeds
This is a method to explicitly prune the local repo, which
users might want to use if they had explicitly removed refs from
the underlying flatpak repo and want to ensure that the objects
referred to by those refs are cleared to save on disk space.
Closes: #1034
Approved by: alexlarsson
In some cases, a user might pull a ref into the local repository and
not deploy it by using FLATPAK_INSTALL_FLAGS_NO_DEPLOY. Later on, that
user might decide that they don't want to deploy the ref after all,
but there was no way to remove that ref from the local repository
in the public API, so it takes up disk space.
Add flatpak_installation_remove_local_ref_sync to remove a given
ref from the local repository if the ref is known and
flatpak_installation_cleanup_local_refs_sync to remove all undeployed
refs.
Fixes#1031Closes: #1034
Approved by: alexlarsson
We have the same flags for flatpak_installation_update and we use
flatpak_dir_install from within FlatpakInstallation but always set
the no_pull/no_deploy flags to FALSE. Previously, passing
FLATPAK_INSTALL_FLAGS_NO_PULL and FLATPAK_INSTALL_FLAGS_NO_DEPLOY
wouldn't do anything because of that.
This has the unfortunate side effect of always returning an error
when FLATPAK_INSTALL_FLAGS_NO_DEPLOY is passed, because
flatpak_installation_install_full tries to get a FlatpakInstalledRef
for the flatpak when it is installed, but obviously it can't do that
since installing an app in an undeployed state doesn't "install" it
so much as just cloning it to the local repository.
As a result, when FLATPAK_INSTALL_FLAGS_NO_PULL is passed, the
FLATPAK_ERROR_ONLY_PULLED Will be set and the caller must respond
accordingly.
Sometimes we need to pull a commit without using static deltas to e.g.
make sure that an app with a corrupted commit can still be updated by
pulling the new commit in full.
This option has been added to the FlatpakUpdateFlags,
FlatpakInstallFlags, as well as a parameter for the CLI.
I set these as separate bits by mistake when there's no good reason for
them to be like that, as they are not flags that are meant to be combined,
but a list of exclusive values.
Implemented the following functions along with the required internal APIs:
* flatpak_installation_get_id ()
* flatpak_installation_get_display_name ()
* flatpak_installation_get_priority ()
* flatpak_installation_get_storage_type ()
It's meant to provide a list of the system installations, not
just the default one, which can still be obtained by calling
flatpak_installation_new_system(), as usual.
Provides access to the functionality offered by the new internal API
flatpak_dir_update_remote_configuration(), in a similar way to what
can be done via the command 'flatpak remote-modify --update-metadata'.
