When getting the dynamic remotes for the installed refs, if no refs
with a collection ID are found, then the ostree_repo_find_remotes_async
is given an array with just NULL, which makes it early return and thus
it would result in an infinite loop in
flatpak_installation_list_installed_refs_for_update.
This patch only tries to find the dynamic remotes when there are such
refs, thus preventing the mentioned error and any extra unnecessary
processing.
Closes: #1587
Approved by: mwleeds
In list_remotes_for_configured_remote(), we call
ostree_repo_finder_avahi_start() without checking the error status. This
means the OstreeRepoFinderAvahi instance passed to
ostree_repo_find_remotes_async() could be in an error state, which leads
to flatpak getting infinitely stuck waiting for the result of that
operation. So this commit removes the OstreeRepoFinderAvahi instance
from the array if it failed to start, and returns early if only LAN
remotes were requested. This is also consistent with how ostree itself
handles an error starting the Avahi finder instance in case NULL is
passed to ostree_repo_find_remotes_async() instead of a finders array.
This error condition happens on the Endless OBS server because there's
no Avahi daemon in the chroot used to run "make check".
Closes: #1587
Approved by: mwleeds
Fetching a remote ref may fail because of the locally configured
collection ID not matching the remote's one (because it's never been set
in the configuration or it's just different/incorrect),
However, using `flatpak_installation_fetch_remote_ref_sync` there's no
mention of the collection ID to the caller, so we should make sure we
try to do our best to match the given parameters. Thus, if the lookup
fails (because the collection IDs don't match), we resort to iterating
over every ref and comparing their names with the expected ones.
This should be however reworked, through a new method likely, in order
to accept the collection ID as an input argument, so the caller has more
power to choose which one to match.
Closes: #1587
Approved by: mwleeds
When listing the removable remotes, it will stop the operation after the
first configurable remote that has no collection ID set.
This is of course a problem as such an occurrence is not a reason for
not trying to list any remaining remotes.
This patch fixes that by simply reporting the failures as a debug
message instead of aborting.
Closes: #1587
Approved by: mwleeds
When p2p is enabled, listing the remotes using
flatpak_installation_list_remotes will include all types of remotes.
However, this can lead to problems for the users since dynamic remotes
(USB/LAN) may not be used always the same way that static ones are. For
instance, when listing the refs in a remote, dyanmic ones cannot be
listed by name; so any existent code that iterates through the list of
remotes and lists the refs in them will not work properly.
To avoid this situation, this patch makes the API method in question to
return only static type remotes. Getting all remotes can still easily be
accomplished by calling flatpak_installation_list_remotes_by_type with a
0-sized array (or by specifying all types).
Closes: #1587
Approved by: mwleeds
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
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
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.
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
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
When a collection ID is set on a remote configuration,
gpg-verify-summary should be set to FALSE because flatpak uses signed
per-repo and per-commit metadata instead. The flatpak command line
already does this (use flatpak remote-modify --collection-id=... and
notice that gpg-verify-summary is then set to false). This commit
changes libflatpak to have the same behavior. Specifically, with a
collection ID set gpg-verify-summary is set to false and otherwise its
value matches that of gpg-verify. This commit also adds a test for this
in testlibrary.c.
Fixes https://github.com/flatpak/flatpak/issues/1479Closes: #1501
Approved by: pwithnall
Mark subpaths as a NULL terminated array. Without this the GIR makes
this a single utf8 parameter and bindings can't use it.
Closes: #1327
Approved by: cgwalters
If you're installing something and its already installed, we undeploy
the old install first before deploying the new. This makes it very
easy to switch an application from one remote to another, without
having to uninstall first, which is both painful and could cause
the download to be unnecessary large.
Closes: #1241
Approved by: alexlarsson
This introduces no functional changes, but makes it a bit more obvious
that we do temporarily have ownership of the FlatpakInstallation
instance.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1138
Approved by: alexlarsson
If a particular system installation is inaccessible (for example,
because it doesn’t currently exist, and we don’t have permissions to
create it), don’t error out of flatpak_get_system_installations().
Instead, do what the documentation says will happen, and ignore the
failure (emit a warning message about it).
The function continues to return an error if *no* installations could be
found.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1138
Approved by: alexlarsson
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.
We're scoping the deploy directory by the subpaths these days, so
we need to take that into account when finding the metadata file.
Fixes https://github.com/flatpak/flatpak/issues/1014
This is declared in the header file, but was never actually implemented.
Oops.
If anybody is hit by this issue, they can work around it by using
g_object_get() to get the FlatpakRemote:type property, which this is the
getter for.
Add it to the tests as well, so it gets exercised.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than a lot of #ifdef mess in the public headers, Alex would
prefer that the P2P API is made unconditionally public. This assumes
that they are unlikely to change in future. If they do, we just make
them return NULL or break API and drop them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This isn’t really used internally, but will be used by gnome-software
for when it configures new flatpak remotes.
This is new public API, but is only declared if compiling with
--enable-p2p.
Includes some basic smoketests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This will only be built when configured with P2P support. We can’t use
glib-mkenums here, as it doesn’t know about the #ifdef
FLATPAK_ENABLE_P2P which surrounds the enum definition. By manually
writing the get_type() function, we can surround it by #ifdefs as
appropriate.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add support for collection IDs to the code which finds and pulls
related refs and other extensions.
Currently, related refs must have the same collection ID as the parent
ref — this is the most likely scenario anyway. In future, it should be
possible to extend the code to support pulling related refs from other
collections.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This adds a new collection-id property which is only enabled if
FLATPAK_ENABLE_P2P is defined. The internal machinery for handling it is
always enabled, to reduce the amount of #ifdef spam.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Also expose a new flatpak_remote_get_remote_type() API so that users can
query what type of remote something is — whether it’s a USB or LAN
remote, or something statically configured.
Make this all conditional on compiling with --enable-p2p.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Search for updates on peer to peer sources as well as the internet in
check_for_updates(), and pass the resulting OstreeRepoFinderResult array
to the pull() calls, so a consistent set of checksums are pulled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
