The underlying setters interpret NULL as 'unset this key', but
we never pass NULL. Since empty strings are not useful values
for title or default-branch or redirect-url, just interpret
an explicit empty value as 'unset this key'. E.g. to unset
the redirect url, use
flatpak build-update-repo --redirect-url= ~/my-repo/
When clients install/update they will see this property in the
(signed) summary and update the url in the config, making this
essentially a permanent redirect.
Whenever you explicitly specify some value (e.g. for
title or default-branch) we set a $KEY-is-set option
to True, and if that is set we never automatically update it.
This ensures that no processes from the build lives
past the return of the build itself, which might
accidentally happen.
We still allow apps to stay around after the regular
flatpak run command finished though, as this is sometimes
done on purpose.
Add a --file-forwarding option for the run command, which triggers
the rest argument processing that was implemented in the previous
commit.
This is how it is used:
flatpak run --file-forwarding --command=cat \
org.gnome.Recipes @@ $HOME/todo @@
Note that the @@ are passed as separate arguments.
At least, to the extent that it is needed for tests to pass.
If any of --show-ref, --show-commit, --show-origin or --show-size
are given, emit the previous one-line format. Otherwise, use the
new, friendly multi-line format.
Sometimes we need to pull a commit without using static deltas to e.g.
make sure that an app with a corrupted commit can still be updated by
pulling the new commit in full.
This option has been added to the FlatpakUpdateFlags,
FlatpakInstallFlags, as well as a parameter for the CLI.
Show the installed and download size for each ref,
when --show-details is given. The tabular display
could be improved by making FlatpakTablePrinter support
alignment at the decimal point.
This is a pretty standalone object, and it is nicer to
have it in its own files. All users have been updated
to include the new flatpak-table-printer.h header.
The installed size in the metadata refers to the full
extension. If we have subpaths, the actual installed
size may be much smaller. Unfortunately, it appears
hard to obtain the actual size, so just hint at this
fact by displaying a '<' before the size.
For now, this just prints bits of summary information in
human-readable form. This command could grow over time
to provide other functionality for managing local repositories.
Show the same data the we show for other refs, when we
list extensions. In addition, show the subpaths if there
are any. Note that this reveals that the installed size
for subpath'ed extensions is misleading, since it is
the installed size for the full extension.
