Use a "Info: " prefix which matches the message printed in
print_eol_info_message(). Also make the message accurately use either
the word "runtime" or "extension" as appropriate.
Based on discussions on the issue tracker, it seems that users sometimes
remove runtime extensions without really understanding whether they're
in use. Add a confirmation prompt to address this.
Helps: #4549
flatpak_dir_list_app_refs_with_runtime_extension() only works when the
runtime extension it is passed and the apps it returns are both
installed. Sometimes a end-of-life message is printed for a runtime that
is not installed but is being installed by the current transaction, or a
runtime that is installed but one of the apps that needs it is being
installed by the current transaction. To cover these cases, check the
operations in the current transaction when building informational
messages about EOL runtimes.
Currently if a runtime extension, e.g.
org.freedesktop.Platform.html5-codecs//18.08 is used by a runtime
org.kde.Platform//5.12 which itself is used by one or more apps, when we
print a message to the user about html5-codecs being EOL, we don't find
any apps using it and don't print any. Fix this by including apps that
indirectly use a runtime extension in the "Applications using this
runtime:" list.
In a later commit we can re-use the helper function added here to add a
confirmation dialog if the user tries to remove a runtime extension
that's being used; currently we just let them remove it.
This is limited to only looking in the current flatpak installation, so
a per-user app using a system-wide runtime extension would not be found.
This is implemented using in-memory caches because otherwise it is
horribly slow; see
https://github.com/flatpak/flatpak/pull/4835#discussion_r876425289
Helps: #3531
This adds a separate, more modern CI build running on ubuntu 22.04
using curl, and leaves the old one around building against soup.
In addition, the modern one uses the system bwrap and dbus-proxy so
that we test these configurations too (and because the modern system
has good versions of these).
I also enabled running parallel make check again, hoping that
whatever made this hang is now fixed. We'll see.
This miniminzes the soup implementation by moving it out of the
highlevel multiple-retry entry points and simplifying the
lower level part to use only one shared helper.
This will also make it easier to replace the soup specific
parts.
This copies and simplifies some helpers from soup:
* Encoding url queries
* Parsing simple http header parameter lists
The goal is to use mostly GUri and a few extra helpers for the flatpak
internals, and then pass raw string uris to the http functions which
could then be backed by any kind of http implementation.
This allows:
* getting http status
* getting www-authenticate header
* Doing HEAD instead of get
This is needed by the OCI registry code for authentication
As discussed in https://github.com/flatpak/flatpak/pull/4582 we
want ot use GUri for soup3, and if we want to use libcurl we might
as well also use it to avoid complex ifdefs, as we're linking to it
already via glib.
This imports a subset of GUri for older versions of glib.
This looks better in case there are warnings or info messages printed
during the update operation, since those are separated from each other
by newlines (at least the EOL ones).
This will be useful in gnome-software's flatpak plugin, which currently
iterates over the operations a few times, and it will be useful
internally as well.
