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.
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.
The st_mtime field is all we can guarantee to keep, so whenever we
write a new summary file for a repo we ensure it is newer than the old
by checking if st_mtime is equal (or less) and if so, use the old
st_mtime plus one.
This means sometimes the generated summary files will be in the future but
that only happens in the corner case of multiple changes inside one
second, and in that particular case we need this change.
This fixes some issues I had with the mtime chacking in the tests due to
the python httpd handling If-Modified-Since based on st_mtime.
These now take (optional) string length args:
flatpak_id_has_subref_suffix()
flatpak_levenshtein_distance()
flatpak_is_valid_name()
flatpak_is_valid_branch()
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.
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/
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
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
This commit is a follow-up for the commit "dir: Validate locally
configured collection IDs". Whereas in that commit we validate the
collection ID in flatpak_remote_state_fetch_commit_object(), here we do
it in _flatpak_dir_get_remote_state(), since fetch_commit_object() is
not called on the code path normally taken for a transaction (only if
try_resolve_op_from_metadata() fails and in other niche scenarios).
This should ensure that if someone erroneously sets a collection ID on a
remote, the error will be caught quickly. It also helps the eos-updater
unit tests pass.
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.
When mirroring to a local OCI dir we apply deltas and generate
uncompressed layer blobs instead of regular blobs. Then we pick this
up on the system-helper side.
This adds the nr of extra datas, as well as the total size in the sparse
cache for all refs that has them. This is what we need for in the download,
and having it in the summary means we don't have to separately download
the commit.
Additionally we add a cache version field to the summary so that we
can know if we can rely on the existance of the new data.
To avoid the complexities of passing (and chaining) OstreeAsyncProgress
objects around, we only create one just before calling to ostree.
The rest of flatpak only ever uses the new FlatpakProgress object.
Co-authored by: Philip Chimento <philip@endlessm.com>
This is a new version of --deploy-collection-id that only applies
the collection id update for new (1.7.x+) version of flatpak clients.
This allows you to enable collection ids for sideload use but not
affect older clients where the p2p codepaths are not as tested.
With the new sideload approach to collection ids it is fine to require
gpg signed summaries. (Not for the child repos or the sideload repos
though, but thoser are either trusted (sideload) or safe for other
reasons like ref-bindings and signed commits).
Allow the app-id or the DConf path to finish with a digit and still be
considered similar enough for DConf migration purposes.
This allows the org.gnome.Rhythmbox3 app-id to migrate its
/org/gnome/rhythmbox DConf path.
See https://github.com/flathub/org.gnome.Rhythmbox3/pull/26
When storing the token-type in the commit and the summary cache we
hardcode it to little-endian.
In theory this breaks the "ABI", but in practice this change is a
no-op on little-endian systems which is what most are. Additionally as most
servers are little-endian this also fixes using big-endian clients with
such servers.
This fixes:
https://github.com/flatpak/flatpak/issues/3434
We can't use the built-in bsearch from the codegen because its an array
instead of a dict, so we have to keep that but its now not using
variant at least.
In flatpak-builtins-build-commit-from.c we call flatpak_repo_collect_sizes()
without initializing the passed in download size to zero, which mean
we sum with sizes with some random value as the start.
This is fixed by having flatpak_repo_collect_sizes() always initialize
the counters to 0 at the start.
Fixes https://github.com/flatpak/flatpak/issues/3362
flatpak build-update-repo now lets you modify the
autenticator-name/install/options keys, and these are migrated to
the summary/metadata during update.
