If the magical io.github.containers.DeltaUrl label is set in the
index, then try to download this to use as the delta manifest for the
image. This allows servers to store deltas outside the registry
itself. The label is propagated to the xa.delta-url metadata in the
generated "fake summary" for the remote, and read back on pull.
Note that the delta manifest layers descriptor will need to have a
"urls" key where it references the blobs if the blobs are also not
stored on the registry.
If the specified manifest doesn't exist or doesn't apply to the target
image we fall back to resolving via the _deltaindex tag.
Call flatpak_remote_state_ensure_summary() before dereferencing
RemoteState->summary to return an error instead of crashing if
downloading the summary failed.
When mirroring to a local OCI dir we apply deltas and generate
uncompressed layer blobs instead of regular blobs. Then we pick this
up on the system-helper side.
This is a version of flatpak_oci_registry_apply_delta() that generates
a new blob in a local repo, rather than a temporary file. This is used
when mirroring using a delta into a child oci registry for system-helper
use.
When we create a system child registry we also set the current token on
it. This is not used directly in the client, however its saved in a
file called .token and re-read in the system-helper, allowing it to
also do the remote registry operations it needs to verify the child
registry.
We typically only load by digest id, resolving tags in other ways.
However, we need to load the _deltaindex tag by tagname, so support
this when possible.
It turns out that libarchive doesn't always read the entire file until
the end if it can figure out that the tarfile ended. Normally this is
not hit, because the decompressor reads all the input, but for
uncompressed tarfiles (like those from applied deltas) this is
important.
If downloading a specific commit (or oci manifest) we may get a 401 back.
If so, request a token and try again. In this case we don't yet know the
token type, so pass MAXINT32 for "don't know".
This downloads a manifest by digest and reconstructs the commit except
for the tree/metadata reference. This allows things like flatpak remote-info
and flatpak update --commit=xxx to work.
Only have the single function flatpak_remote_state_load_ref_commit()
that loads the commit objects (and don't support loading other types
of objects as that is not used).
This is a minor cleanup, but it also will be useful later when
we want to be able to "load" commits from OCI repositories.
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.
