We store the cached subsummaries as `$remote-$arch-digest.sub`, this
way we can prune everything but the most recent (i.e. highest mtime)
rather than looking at the index. This way we don't prune old
subsummaries for other arches when we update one arch, which would not
let us use deltas for those.
Some details:
* If mtimes are identical (mtime precision issue) for several
subsummaries we keep all.
* If we just saved a subsummary in the cache we don't prune that
in case there is something wonky with mtimes.
The subsets for a remote are pruned every time we write a new cached
subsummary.
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.
In addition to the old summary file we create a summary.idx and
a set of per-arch subsummaries (and extra copies of these if any commit
specify a subset). These are much smaller, and eventually we will also
get deltas for them.
We are not yet using these new formats, although the code is there
to use them once we start downloading them.
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.
This moves the generation of the summary files completely into flatpak
allowing us to (later) customise what goes into it in more detail and
generate other forms of summaries.
If accountsservice isn't available on the system bus, then we can't
ask it for the user's parental controls settings, and we also can't
ask it whether it even has the malcontent extension. Since this is
not a real security boundary, fail open.
This can be dropped if we depend on a version of libmalcontent that maps
these errors to MCT_APP_FILTER_ERROR_DISABLED.
Resolves: https://github.com/flatpak/flatpak/issues/3902
Bug-Debian: https://bugs.debian.org/972138
Signed-off-by: Simon McVittie <smcv@collabora.com>
Sometimes a server might return a HTTP error 500 (this seems to happen
sometimes with Microsoft’s VSCode server, for example). Map this to
`G_IO_ERROR_HOST_UNREACHABLE` for now, which is a bit more specific than
returning `G_IO_ERROR_FAILED`, but without the hassle of introducing a
new public error domain which could give more detail.
In particular, this should allow gnome-software to show an error message
to the user for such failed downloads, rather than hiding the error and
logging the following:
```
not handling error failed for action download: While downloading http://packages.microsoft.com/repos/vscode/pool/main/c/code/code_1.45.1-1589445302_amd64.deb: Server returned status 500: Internal Server Error
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
flatpak_installation_list_installed_refs_for_update() now uses the
ready-pre-auth signal instead of the ready signal. This means we will
report updates even for refs that require authentication to install.
This is similar to the ready signal, except it is called before
per-ref authentication. Apps can use this if they want to be able
to ask for user input on progress before asking for authentication.
This is nice to be able to do in general, but it is also required for
the implementation of
flatpak_installation_list_installed_refs_for_update(), as it doesn't
install any authentication handler, so it will never report updates
for protected refs if using the ready signal.
Note: In special cases we will require authentication even earlier
if authenticating is needed during the resolve operation. This happens
for instance if you are doing a update to a particular commit (rather
than the lastest commit) where we need to get the commit object directly.
It is very much possible for an invalid ref name to occur, either due to
lack of validation on Flatpak creation like #3887, or just any
manually-written ref name due to skipping Flatpak tooling or malicious
intent. Regardless, this shouldn't crash, so check the names before
creating the transaction ops.
Fixes#3887.
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.
If we're auto-installing dependencies we want to limit them to those
from the same remote. However you can still (manually) install such
dependencies, so when we're looking for things to possibly uninstall
we need to check dependencies from all remotes.
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.
We normally don't remove a runtime when the last app using it is
uninstalled, since runtimes are large and re-downloading it in the
future may be difficult. But if the runtime is end-of-life, there's a
reasonable chance it won't be used again, so uninstall it in that case.
Similarly, if the last app using a runtime is upgraded to a different
runtime, and the runtime is EOL, uninstall it.
A unit test is included, and the subsequent unit test also had to be
modified. Otherwise we get a "Update is older than current version"
error, since the runtime is installed from test-repo but
setup_repo_no_add() calls make_runtime() which uses the one in
runtime-repo instead, which is older than the one in test-repo.
In a few places we are using
flatpak_installation_list_unused_refs() and then only
using the ref strings not the FlatpakInstalledRef objects, so the
resources used to construct those objects are wasted. Add a flatpak_dir_
function to be used internally instead. One day we will figure out how
to make flatpak-dir.c less of a wilderness.
This also adds the flatpak_installation_list_unused_refs_with_options()
verion that has extended features.
commit 6b46d9a0ed that added DConf path
skewering to camelcase conversion only allowed it in one direction
(skewered path1 and camelcase path2).
That turned out to be not enough to allow /org/gnome/sound-juicer/ to
/org/gnome/SoundJuicer/ conversion as the caller had the
flatpak_dconf_path_is_similar() arguments the other way around.
This commit implements it both ways to avoid confusion which way it
should be called.
F: Ignoring D-Conf migrate-path setting /org/gnome/sound-juicer/
Allow a snake-case in the app-id to convert to a '-' or '_' in the
DConf path to be considered similar enough for DConf migration purposes.
This allows the org.gnome.SoundJuicer app-id to migrate its
/org/gnome/sound-juicer DConf path.
F: Ignoring D-Conf migrate-path setting /org/gnome/sound-juicer/
This is no longer needed since a FlatpakRemoteState is passed in, which
ensures the repo exists. The similar call was already removed from
flatpak_dir_install().
