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.
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.
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).
We need to get the commit object to setup the extra-data progress information,
and this is currently done using a complex pull operation to a temporary
repo. According to https://github.com/flatpak/flatpak/issues/3515 it
even causes an unecessary download of the summary in some cases.
Now that we don't need to support p2p we can instead directly download
the commit object using a simple http operation (or from the sideload
repos), as we know the commit id at this point anyway.
I noticed several places in flatpak-dir.c that didn't check for
NULL progress, so lets move the check inside the implementation so
we can ensure its always checked.
To avoid the complexities of passing (and chaining) OstreeAsyncProgress
objects around, we only create one just before calling to ostree.
The rest of flatpak only ever uses the new FlatpakProgress object.
Co-authored by: Philip Chimento <philip@endlessm.com>
A make rule like
a b: x y
command
does not mean "run command to generate a and b from x and y". Instead,
it means "run command to generate a from x and y", and, separately,
"run command to generate b from x and y". In a parallel build this
could mean that we try to run the variant-schema-compiler twice, in
parallel, with the output from each run overwriting the other.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This means it doesn't go into dist tarballs, and we don't need to add
it to BUILT_SOURCES and CLEANFILES separately because it's already
there.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Instead of having a global config option we scan a directory for
symlinks into the sideload repos. These come from
/var/lib/flatpak/sideload-repos and /run/flatpak/sideload-repos (for
default system installation).
This is much easier to update atomically, and the two different
options are useful for persistant (the first) or dynamic (the second)
usescase.
Fixes https://github.com/flatpak/flatpak/issues/3494
