We don't guarantee that the active link is identical to the
checksum anymore. If you really need the checksum you have
to look at the deploy data.
This is mainly changing the names from "checksum" to "active_id"
in the code that touches the active link, except the case where
we're undeploying after an update. We then use the old active
link value rather than the old commit id as the undeploy id.
This will allow us to have partial deploys with different names
than the full or differently partial deploy.
This removes some duplicated code, and also follows the new
redirect-url property on initial add.
This also means we're requiring gpg signatures to be correct
on remote-add, so fix up the tests
If the ref specified in "branch" is actually a tag, we were requiring
that the "commit" property must match "git rev-parse $branch", but
in the case of a tagname that actually expands to the id of the
tag object, not the commit id. We now also try to match against
"rev-parse $branch^{commit}" which expands to the actual commit
object.
We still allow the tag object for backwards compat.
Rather than just prepending _tmp this creates a unique
directory name, which means we don't run into issues
when retrying if the first checkout fails.
Fixes https://github.com/flatpak/flatpak/issues/786
It turns out the underlying call ostree_repo_query_object_storage_size
doesn't work for staged objects, so we work around this by actually
loading the object, walking back to the original unix input stream
and fstat:ing the fd from that.
I just saw a confusing error messages that looked like two error
messages just running into each other. Better to end the first
one with a colon when using g_prefix_error.
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.
We download the summary and send it to the system helper, it verifies
the checksum and applies the changes, with the same polkit permissions
required as for an app update (i.e. typically none).
This allows us to update metadata automatically, without permission
requests.
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.
