Currently if you run "flatpak update --commit=XYZ", we try to use that
commit for every installed thing, which doesn't make much sense. Make it
an error not to specify a ref with --commit.
The newly added https://systemd.io/DESKTOP_ENVIRONMENTS/ lists an XDG
defined specification for how cgroups for applications should be named.
This will allow flatpak's to correctly follow any drop-in's set for
applications on the system as well as help next-gen system monitor's
treat flatpaks as applications.
flatpak-session-helper.service is unaffected.
When we add significant new source strings downstream, Endless adds
projects to our Transifex instance to get translations from paid
translators and community contributors.
Since we no longer add new source strings to Flatpak, we're removing it
from our infrastructure. I checked which strings we have translations
for downstream that are not present (if perhaps different) upstream, and
these German translations from a community member are it.
While it can be worked out from the context, it’s clearer to state the
units that download and installed sizes are calculated in explicitly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Make it explicit that skipped ops are excluded when returning the ops in
a transaction, or when working out whether it’s empty.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This exposes the `skip` member of `FlatpakTransactionOperation`, as it’s
needed for callers to usefully traverse the operation graph (which is
now accessible using
`flatpak_transaction_operation_get_related_to_op()`).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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).
