Re-implement flatpak_installation_list_installed_refs_for_update() using
a FlatpakTransaction, so we can guarantee it always gives the same set
of things to update as the update command. This API is used by GNOME
Software and many times in the past g-s has not shown the same list of
apps to be updated as the flatpak CLI. See:
- https://gitlab.gnome.org/GNOME/gnome-software/issues/539
- https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/430
This commit also expands the unit tests for this API, which were already
quite good. Now we test that missing subpaths of locale extensions show
up as updates, and updates that have been pulled but not deployed show
up as well. The latter is a break from how this function used to behave,
but it seems unlikely to break any application.
Currently, if you add an app update to a transaction and its locale
extension does not have subpaths installed for every configured
language, the locale will be updated accordingly. But if you add only
the locale extension to the transaction to be updated, the transaction
is a no-op because we treat subpaths == NULL to mean the currently
installed set of subpaths, and
flatpak_dir_needs_update_for_commit_and_subpaths() decides there's
nothing to do.
This doesn't seem like the right behavior, so update
flatpak_transaction_add_ref() so that we take the configured set of
locales into account as we do in add_related().
This will help the unit test in the following commit to pass.
This will be used in the following commit, so we can track what
installed thing needs an update when there's a transaction operation to
e.g. install its missing runtime or extension.
Currently when you create a FlatpakQuietTransaction object using a
FlatpakDir, the dir will have no_interaction set to TRUE even after the
transaction runs. I don't think it makes sense to have a side effect
like that, and it causes the remote-delete command to fail in the case
where it has to uninstall things. So, restore the old no_interaction
value during destruction of the FlatpakQuietTransaction.
Fixes https://github.com/flatpak/flatpak/issues/3140
This adds the nr of extra datas, as well as the total size in the sparse
cache for all refs that has them. This is what we need for in the download,
and having it in the summary means we don't have to separately download
the commit.
Additionally we add a cache version field to the summary so that we
can know if we can rely on the existance of the new data.
We used to always create a commitpartial file in child repo, because
ostree doesn't follow parent repos when loading commitpartial state,
and when the commit was in the parent repo it would find the commit
but no commitpartial and assume the commit was complete and do nothing.
However, having a commitpartial file seems to break delta downloads in
ostree, as per: https://github.com/ostreedev/ostree/issues/2053
causing us to download too much data when using deltas.
So, we now only create a commitpartial if there is one in the parent
repo. This still means we will get the ostree problems in case there
is one, but in the much more common case we avoid the issue.
In order to "fix" the uncommon case we also (separately) cap the
reported progress at 100%. (We should probably also fix the upstream
ostree issue too.)
Due to bugs in ostree (see
e.g. https://github.com/flatpak/flatpak/pull/3524) it sometimes
happens that we download more data than we expect to. This isn't
great, but when it happens its better to limit the progress to 100%
anyway to avoid breaking apps (for example, the flatpak CLI doesn't
really handle this very well).
