This works around:
https://github.com/ostreedev/ostree/issues/541
Which is causing us to not pull the entire set of objects, rather
stopping at the first object which is locally available. We fix
this by pulling twice in the subdirs != NULL case, which works
because the second time the new commit is marked partial and
we then pull the entire thing.
This means we will not end up with a partial download if something
goes wrong during the extra-data download, because we don't
commit the downloaded base files until everything is finished.
Note, this requires the latest ostree for this feature.
If the downloaded app has a "xa.extra-data-sources" property in
the commit, then we download these as part of the pull operation
and store the result in the commitmeta object in the repo.
Then during deploy we look at the xa.extra-data-sources properties
again and extract them from the commitmeta into /app/extra
in the app, and afterwards we run /app/bin/apply_extra in a minimal
sandbox that has read-write access to /app/extra, but nowhere else.
There are some complexities:
We need to re-verify when extracting, because the commitmeta is not
really signed, so we could have picked up random stuff there
from the upstream repo, or from an attacker misusing the system-helper
local install codepath.
When using the system-helper the pull will fail if the commitmeta
is to large, so we have some code in this case to manually transfer
the larger commitmeta on the side to the local-pull code.
When an application requires a runtime that is not installed, search
for it and prompt for permissions to install it. Also, update required
runtimes when the app is being updated.
If this is set for a remote we will never automatically look for
dependencies in it. This makes dependency search faster, as we
don't need to search in app-only remotes.
The new function flatpak_dir_update_remote_configuration() can be called
to fetch the contents of the summary file from the remote's source location
and update the local configuration in the installation directory accordingly.
For now, only the xa.title and xa.default-branch configuration parameters
are supported, since those seem to be the only relevant ones at the moment.
If no branch is explicitly stated when installing a flatpak, and several
options (branches) are available for the same ID, we now check the remote's
default branch and use that one, if it's defined and available for the app.
https://github.com/flatpak/flatpak/issues/221
Just like we do with the title, fetch the default-branch from the
repository's summary file and use that information when adding a
remote reference from the command line.
https://github.com/flatpak/flatpak/issues/221
For now this is a purely client side setting which lets you store
the default branch to use for a remote. This is mostly meant to
be used for UI tools, although the CLI could also be made to use this.
You can set this manually in the CLI with --default-branch, or via a
flatpakrepo file (new key DefaultBranch).
This means that the remote is there, but disabled.
This is needed for e.g. bundles without origin url, and when bundles
starting using this codepath this regressed like in:
https://github.com/flatpak/flatpak/issues/314
These are similar to .flatpakrepo, but for a single app.
For example, if you have a file gedit.flatpakref with this:
[Flatpak Ref]
Title=GEdit
Name=org.gnome.gedit
Branch=stable
Url=http://sdk.gnome.org/repo-apps/
IsRuntime=False
GPGKey=mQENBFUUCGcBCAC/K9WeV4xCaKr3NKRqPXeY5mpaXAJyasLqCtrDx92WUgbu0voWrhohNAKpqizod2dvzc/XTxm3rHyIxmNfdhz1gaGhynU75Qw4aJVcly2eghTIl++gfDtOvrOZo/VuAq30f32dMIgHQdRwEpgCwz7WyjpqZYltPAEcCNL4MTChAfiHJeeiQ5ibystNBW8W6Ymf7sO4m4g5+/aOxI54oCOzD9TwBAe+yXcJJWtc2rAhMCjtyPJzxd0ZVXqIzCe1xRvJ6Rq7YCiMbiM2DQFWXKnmYQbj4TGNMnwNdAajCdrcBWEMSbzq7EzuThIJRd8Ky4BkEe1St6tuqwFaMZz+F9eXABEBAAG0KEdub21lIFNESyAzLjE2IDxnbm9tZS1vcy1saXN0QGdub21lLm9yZz6JATgEEwECACIFAlUUCGcCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEArkz6VV0VKBa5cH/0vXa31YgEjNk78gGFXqnQxdD1WYA87OYxDi189l4lA802EFTF4wCBuZyDOqdd5BhS3Ab0cR778DmZXRUP2gwe+1zTJypU2JMnDpkwJ4NK1VP6/tE4SAPrznBtmb76BKaWBqUfZ9Wq1zg3ugvqkZB/Exq+usypIOwQVp1KL58TrjBRda0HvRctzkNhr0qYAtkfLFe0GvksBp4vBm8uGwAx7fw/HbhIjQ9pekTwvB+5GwDPO/tSip/1bQfCS+XJB8Ffa04HYPLGedalnWBrwhYY+G/kn5Zh9L/AC8xeLwTJTHM212rBjPa9CWs9C6a57MSaeGIEHLC1hEyiJJ15w8jmY=
You can then install gedit with
flatpak install --from gedit.flatpakref
This replaces all current callers of gs_file_ensure_directory with
equivalent code.
Actually, two instances were calling gs_file_ensure_directory with
FALSE, i.e. error out on EEXIST, but those cases seem fine with the
do-nothing-if-exists semantics.
This lets us find all the "related" refs to a ref in a particular
remote, or locally. These are the things we should automatically
download or delete when installing/updating/uninstalling the ref.
The implementation currently looks at all the extensions handled by the
app/runtime. For debug extensions and extensions marked no-autodownload we
only consider them related if its already locally installed. For locale
extensions we always consider them related, but we only pull the current
locale data for it.
This lets distributors share a system copy of bubblewrap (>= 0.1.0)
between Flatpak and any other projects that benefit from it, if they are
careful to keep new versions in sync. The default is still to use the
bundled submodule, ensuring compatibility and simplifying dependencies.
Enable $PATH search everywhere that runs bwrap, so that $BWRAP doesn't
necessarily need to be a fully-qualified path.
Signed-off-by: Simon McVittie <smcv@debian.org>
Due to an issue with ostree (https://github.com/ostreedev/ostree/pull/362)
applying non-from-scratch deltas fail when using parent_repo such as
in the system-helper case. We fix this temporarily by disabling the
use of deltas for that case.
This has several improvements:
* Writes to a temporary location and renames at the end, so
we never end up with partial checkouts.
* Don't fsync each file during checkout, instead syncfs() at
the end
* Pre-create the target deployment directory so that we get the right
permissions for it.
For a local (file:// uri) remote, do an (untrusted) direct pull instead
of pulling into the users cached repo first. This way we do less copies,
as well as guaranteeing the source of the data. The later means its
mostly safe to also allow this for non-gpg signed remotes.
ostree_repo_remote_fetch_summary can set out_summary to NULL but
still return TRUE according to the documentation, so don't assume
that *out_summary will always be set.
We need an actual active installation, not just the base directory.
This caused a failure if the user had tried to install and app but the
installation failed. After that installation failed due to it claiming
to be installed, while uninstall failed due it it *not* being
installed.
Alexander Larsson