This removes flatpak_dir_list_remote_refs() and
flatpak_dir_list_all_remote_refs() which have no more users, as everything
migrated to the _decomposed() versions.
This means we do a bit less string operations, but it also allows us
to pick up the collection-id when listing refs from a file: uri, fixing
the issues described in https://github.com/flatpak/flatpak/pull/3909
This slightly changes the behaviour of collection ids and remotes.
When listing regular remotes we only ever return the refs with the
collection id specified by the configuration of that remote. However,
when specifying a file: uri for the remote name we return all the refs
in the repo, with their corresponding collection id.
This means the test suite has to change a bit as before we returned
all the collrefs from the remote, not just the one matching the configured
collection id.
If you're listing a file: uri we (as before) add the collection-ref
tables, but we now also set the proper collection-id for the main ref
table if the ostree.summary.collection-id key is set.
flatpak-utils.c is getting large, and also I got some issues with
include order, so split out things that are purely handling ref stings
in various ways to its own file.
If you are listing a remote named (e.g.) file:///some/path/to/repo then we
have no idea what the actual collection id is for that remote, so we can't
pick the right part. In practice, this is typically done when listing
a side-load repo, such as described in
https://blogs.gnome.org/mclasen/2018/08/26/about-flatpak-installations/
or by the endless software installer that lists available offline apps.
This kinda abuses the FlatpakDecomposed object to store the collection
id, even if that doesn't normally carry this. This is not optimal, but it
is kind of a weird case and there isn't really any other place for it that
makes sense either, and having it there is efficient and keeps the APIs.
getters now have three forms:
const char *foo_peek() returns pointer into data and length
const char* foo_get() returns zero terminated pointer into data
char *foo_dup() returns allocated zero terminated pointer
Not everything has all of these (as that is not always possible), but
it is clear what each one does.
We also now support storing a collection id for a
FlatpakDecomposed. This is not typically done (as we use the source
remote to define the collecion id and don't expose this concept to the
user). However, for the case when directly listing a local repo (such as
a side-load repo) we need this.
We now validate the arch string. The valid chars are a-z, A-Z, 0-9 and
_. This was't previously verified, but no arches in existance have other
chars.
There is a new flatpak_decomposed_new_from_decomposed() which lets you
modify part of another ref. Say replace the arch or the branch and
keep the rest the same.
We used to go:
* indexed summary memory cache
* indexed summary fetch
* compat summary memory cache
* compat summary fetch
But now we go:
* indexed summary memory cache
* compat summary memory cache
* indexed summary fetch
* compat summary fetch
This means in the compat case we don't constantly have to fail the
summary fetch before using the memory cache.
This moves a bunch of code from FlatpakDir to FlatpakTransaction which was
only used to find dependencies. This allows us to reuse the existing
cache of FlatpakRemoteState objects in the transaction.
