If the bundle contains an origin link we can now install related
things from it, such as locale data.
You can also build the bundle with --runtime-repo=URL, where the url
points to a flatpakrepo file for a repo with runtimes. This works
similar to the RuntimeRepo= feature in flatpakref files.
There will be a way to retrieve the list of all system installations,
not just the default one, so we rename this for backward compatibility.
Note that some (most?) of the places where we will be now using this
renamed function will likely have to migrate to using specific system
installations, but we don't have the necessary APIs yet so we do this
as an initial step to all the incremental changes that will come next.
If you're building a runtime and have a base runtime with expected
extensions, fail to build if the actually installed extension is
partial (i.e. if it has a subdir specified).
Fixes https://github.com/flatpak/flatpak/issues/390
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.
Add support for this flag in build-update-repo, so that we can define
a default branch in the server side, to be picked by the clients.
https://github.com/flatpak/flatpak/issues/221
Instead of using "NAME [BRANCH]" as the command list we now
support REF..., where each REF can be partial. This is easiest
explained by examples. Here are some valid refs:
org.test.App - only app id
app/org.test.App/x86_64/stable - full ref
org.test.App/x86_64/stable - full ref without prefix
org.test.App - only app id
org.test.App//stable - only branch
org.test.App/x86_64 - only arch
If any parts are left out they are wildcarded. Such parts are filled
first by looking at other command line arguments like --arch and
--app/--runtime. And finally by looking at what is available in the
remote. If there are multiple matches the user is told the options
in an error message.
It turns out that live apps were exporting files with dashes
other than "-symbolic". For instance "org.libreoffice.LibreOffice" was
exporting "org.libreoffice.LibreOffice-writer.desktop".
Allowing any dashes in the last segment like this is really no diffent
than allowing org.libreoffice.LibreOffice.writer.desktop which we
already do. Any conflicts here are under the control of the owner
of the org.libreoffice prefix.
However, allowing dashes in the earlier segments is more problematic.
For instance, any file exported by "org.my-foo.App" could conflict with
an app called "org.my" if this was allowed.
So, as a middle ground, we're allowing dashes in the last segment of
the App id only.
For a long time we have been disallowing "-" in application names,
which is different than what dbus allows for bus names. Also "-" used
to be not allowed by GApplication in glib. This is in part because
dbus object paths do *not* allow dashes, so you can't legally map
from e.g. a valid name like "org.foo-bar.gazonk" to a valid path
like "/org/foo-bar/gazonk".
This is a problem because many existing apps already use "-" in the
name, either as the last part (org.gnome.font-viewer) or because
the dns name it refers to has a dash.
This was recently discussed in the dbus community, and the result
is to recommend that "-" in the bus names be converted to "_" in object
paths.
This change makes it also allowed to have "-" in a flatpak app id.
For flatpak specifically we were relying on "-" not being allowed to
handle the case of exporting "org.foo.App-symbolic.png". If "-" is
allowed this name can conflict between apps called "org.foo.App-symbolic"
and "org.foo.App".
To handle this we add two special cases:
* App ids can't end with "-symbolic".
* Apps are allowed to export files with $appid-symbolic as prefix.
This enables support for ptrace and perf for the app, similar
to what run -d manually gave you before. This is nice to be
able to package an app like gnome-software.
If there are multiple refs pointing to the same revision, then
collecting the size and metadata info for each of them is wasteful.
Maintain a hash table of the data so that it's only collected once per
revision.
This slightly widens an existing race where a ref could be updated
before the summary file is regenerated. In that case, the data in the
xa.cache variant would correspond to the wrong revision. I don't believe
this can be fixed unless there's locking at the ostree level.
If there are non-flatpak refs in the ostree repo, there's no use in
collecting size or metadata information for them. Instead, only operate
on refs in the appstream, app or runtime prefixes.
Alexander Larsson