These now take (optional) string length args:
flatpak_id_has_subref_suffix()
flatpak_levenshtein_distance()
flatpak_is_valid_name()
flatpak_is_valid_branch()
We need to load the ensure the right arch whenever we need it.
Also this restructures the RemoteState handling a bit in general so that
we avoid loading the same remote state multiple times when converting
partial refs to full refs.
This drops the deltas from the summary and uses the per-commit
metadata field to add the cache data to avoid the need for the separate
xa.cache and xa.sparse-cache indexes. This way we avoid repeating the
refs in multiple places.
Nothing uses this format yet, but we still pass make check if we enable
it.
If possible, ask for confirmation of the entire transaction before
starting to do the per-ref authentication. We do this by splitting
the current "ready" callback into two parts, one in ready-pre-auth
and the rest in ready.
There is some complexity added because if we do any authentication
between the two signals we can't back-patch the transaction list we
already printed. To handle this we detect this case and re-print the
table if this happens.
This change makes repair print the current ref number being verified
and the total number, that way the user can observe the repair progress.
In addition, if fancy output is not disabled, the progress will be
cleanly printed on a single line.
On a dry run, this also will still print the delete messages without
actually performing the operations, to show what actions would be
taken on a non-dry-run.
This way we can get the proper eol status for the new to-be-installed
refs, rather than whatever was previously installed. This allows us to
detect when a runtime is updated and the new one is eol, and nothing
uses it, so it can be auto-uninstalled.
Rather than trying to figure out which runtimes are affected byt
the current setup of ops we run flatpak_dir_list_unused_refs() twice,
once with and once without the changes the transaction will cause.
Any unused refs after the transaction that were not unused before are
caused by the transaction and we start uninstall ops for those.
Also rename flatpak_dir_list_unused_refs_with_options() to
flatpak_dir_list_unused_refs() as it need not be so long.
In case a runtime becomes unused and then later becomes End-Of-Life, it
is currently not removed. So this commit removes such runtimes in the
update command, as discussed in #2639. A unit test is included.
I am planning to propose to use the FlatpakTransaction API added here in
gnome-software, so that users don't have to use the CLI at all for
runtimes to be cleaned up. KDE Discover already removes unused runtimes
periodically.
Avoid shadowing variables that are already declared in a previous scope,
and make such occurrences compile-time errors. These are not functional
changes.
In a few places do related code cleanup.
A similar ostree PR is here:
https://github.com/ostreedev/ostree/pull/2195
When "flatpak uninstall --unused" is run, we don't remove unused
runtimes that are pinned. List them in the output so the user knows they
are being left installed.
This commit also adds new library API,
flatpak_installation_list_pinned_refs().
If a runtime is installed explicitly rather than as a dependency, pin it
so it doesn't get automatically removed when unused runtimes are being
removed. We do this because the runtime might be installed for
development or other uses.
This commit also rearranges some code in the mask and pin commands, and
adds a unit test.
As discussed here [1], we want a way to mark runtimes to be kept even
when they are unused by any apps and we are removing such runtimes.
Currently this is a command that can be run manually; a subsequent
commit will pin runtimes automatically if they are installed
independently of any app.
A unit test is included.
[1] https://github.com/flatpak/flatpak/issues/2639#issuecomment-662311756
Commits 32194f2d2 and b8d2196c2 made create-usb detect partially
installed commits and omit them except when --allow-partial is specified
(and in the case of extensions of related refs omit them
unconditionally). The reasoning was that if on the other computer using
the USB for an installation you need a different subpath of a commit
(such as a different language of a locale extension), the installation
will fail. But in most real world cases the users on both ends will
speak the same language so it will not often be an issue. Also, if you
are offline and have only your own language's subpaths for your locale
extensions, it makes sense to put them on the USB because you have no
way to get the full locale extension and the receiver probably wants the
same subpath as you.
The way "flatpak create-usb" is most often used in Endless is via
gnome-software which calls it under the hood. So while we could have it
pass --allow-partial that would not accomplish much; it doesn't solve
the problems above.
For the online case we may want to attempt to download the full locale
extensions before copying to the USB, but that is for a later commit.
Fixes https://github.com/flatpak/flatpak/issues/3491
This is useful if to avoid changing the no-interaction of the whole
FlatpakInstallation. Also, having this per transaction lets us
clean up the code in FlatpakQuietTransaction a bit.
flatpak enter must not be multi-threaded because it calls setns. This
was causing a problem because g_vfs_get_default spawns threads in some
environments.
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.
A repository needs to exist for a remote to be written inside,
otherwise the OstreeRepo instance will be NULL and a crash will
occur once the instance is accessed.
Fixes#3612.
