Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport scratch-delta support #3415

Merged
merged 4 commits into from Feb 14, 2020

Conversation

alexlarsson
Copy link
Member

This is a backport of fix to use static-deltas to the 1.4 branch.
Additionally it also has some fixes to make the tests pass on python3-by-default distros and a backport of a p2p mirror-ref fix that is needed for the static-delta fix.

alexlarsson and others added 4 commits February 14, 2020 10:47
On master we're python3 only, but there is no need to change this for
the 1.4 branch.

However, some recent systems have the /usr/bin/python being python3,
which breaks the tests. So, we hardcode python2 to make it work on
these systems.
This reverts commit 915ad58.

This commit turned out to have unintended side effects. Specifically,
with it we do a pull with OSTREE_REPO_PULL_FLAGS_MIRROR, and then
flatpak_dir_setup_extra_data() does a non-mirror pull in the same
transaction, so the ref being pulled ends up being written to disk under
both refs/remotes/ and refs/mirrors/ in
ostree_repo_commit_transaction(). This is a problem because only the
remote ref is deleted during an uninstall, so the disk space is leaked,
and we don't have the infrastructure in place to keep both refs up to
date as they're updated.

It would be nice to consistently use OSTREE_REPO_PULL_FLAGS_MIRROR for
all pulls but that turns out to be a deep rabbit hole to go down; see
the discussion in flatpak#3220

So revert the commit instead (with a few exceptions: keep a
still-relevant FIXME comment, keep an assertion in the "out:"
section, and keep a debug statement printing out the resolved rev).

Note that this means that since we're no longer checking commit
signatures during ref resolution, in theory remote B could try to set
the same collection ID as remote A and serve a malicious update for
something from remote A, but the signature would be found to be invalid
during the pull phase due to our use of "ref-keyring-map" so the
transaction would fail.

All the other uses of OSTREE_REPO_PULL_FLAGS_MIRROR across the codebase
should be kept I think:
- flatpak create-usb uses it when pulling into the repo on the USB which
works perfectly well with refs/mirrors/ (and the USB is mirroring the
collection-refs!)
- it's used when pulling into a temporary "child" repo in a few places
and there it makes sense since the child repo is mirroring the refs so
they can be pulled into the main repo. In fact, in the case of
flatpak_dir_do_resolve_p2p_refs(), we need MIRROR since otherwise
ostree_repo_resolve_collection_ref() gives us the commit on-disk
rather than the just-pulled one that's in memory.

(cherry picked from commit 1336652)
This breaks Deploy which can't find the ref. It used to work due to
the extra non-mirroring pull in flatpak_dir_setup_extra_data, but
this is not needed here.

(cherry picked from commit 9aecad7)
As noticed in flatpak#3412 we
regressed at some point and are no longer using from-scratch deltas.
This is caused by an optimization in ostree where it decides to not
use a from-scratch deltas if theres is *some* version of the ref
locally available.

This conflicts with some code in flatpak that pulls *only* the commit
object in order to look for extra data size information so that we can
get the progress reporting right. Unfortunately the existance of
just the object triggers the above causing us to *never* use from-scratch
deltas.

We fix this by throwing away the partial pull in an aborted ostree
transaction.

(cherry picked from commit b371ef9)
@alexlarsson alexlarsson merged commit 557e809 into flatpak:flatpak-1.4.x Feb 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants