If directory is "foo" and the extension id ends with ".ext" and
subdirectory-suffix is "sub" then the extension point will
be "/usr/foo/ext/sub" rather than just "/usr/foo/ext".
This is very useful when the extension point naming scheme is
"reversed". For instance, this happens for the /usr/share/themes directory.
An extension point for a gtk3 theme would be in /usr/share/themes/$NAME/gtk-3.0,
which could be achived by using subdirectory-suffix=gtk-3.0.
If your extension points set this, then each extension will have
the corresponding subdirectory added to LD_LIBRARY_PATH.
We also support a priority property in the ExtensionOf group
in the extensions themselves to set the search order.
Even without -d this shows the whole ref, as well
as the source of the app (user/system) and if it
is a runtime.
This is important now as the default is to show
both user and system and both apps and runtime.
We make /etc just a symlink to /usr/etc when we're building a runtime
and /etc is supposed to be writable. Otherwise the bind-mount we
normally have there don't allow use to replace existing files in /etc.
Before this commit
$ flatpak install --arch someArch --from some.flatpakref
Would completely ignore the arch argument and only install for the
default flatpak architecture. Since flatpakref files don't include
an arch field, there's no reason we can't attempt to install the
arch specified on the command line.
This change fixes GCC compiler warnings where a cleanup function was
specified on an uninitialised pointer, which in the view of GCC could
result in an errornous free of uninitialised memory, if the functions
that initialise them do not return NULL.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
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.
Also, refactor code that finds and prints the references with flatpak list,
as this needed to change a bit when considering multiple installations, as
the current code was not flexible enough for dealing with that.
User and system installations is no longer a binary decision, so remove
this API to force explicit calls to either flatpak_dir_get_system_default()
or flatpak_dir_get_system_list() when dealing with system installations.
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.
We recreate the OstreeRepo object in order to flush out any configuration
changes done via the system helper, so that changing the configuration works.
Should fix https://github.com/flatpak/flatpak/issues/413.
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
We juse use g_file_new_for_commandline_arg instead of g_file_new_for_path.
This is somewhat related to https://github.com/flatpak/flatpak/issues/401
but doesn't actually handle the specific case of tilde.
Its pretty common to e.g. ship an icon theme bundled in the app,
but you then don't want to have a warning for every file.
So, instead make this a debug message.
It makes no sense to allow you to install an application systemwide
if it only works for your user. However, its generally fine if to
install a per-user app that relies on a system-installed runtime.
In particular, this fixes installing system-wide extra-data apps where
we need the runtime to be system-installed to run the unpack script.
The g_key_file_load_from_bytes() function was added in GLib 2.50, and that
is too high as flatpak wants to support centos7/rhel7, which is now in 2.42.
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.
If you put a section like:
[Extra Data]
uri=https://sdk.gnome.org/gno%6De.flatpakrepo
checksum=ace1b504d32eefdf05b53044e6f785fe7886cc5657b5df034c3b9ac8e3aeb70c
size=1335
uri2=http://sdk.gnome.org/gedit.flatpakref
checksum2=d8baa109fb5fdcfe90379f3e93c5ab29f11772b42bf569bb3481e4aff489b0dd
size2=1472
name2=renamed.flatpakref
Then this information will be put in the commit object and the
later will be used when downloading the app.
This means you can do:
flatpak run org.freedesktop.Sdk
to get a shell in a sandbox with that runtime, but with an
empty /app.
You can also specify a particular runtime branch and command like so:
flatpak run --command=ls org.gnome.Platform//3.22 /
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.
Otherwise we'll be always trying to force the installation from the
default branch for a repo, regardless of whether the app being
installed is available for that branch.
This new command relies on flatpak_dir_update_remote_configuration()
and allows updating the local configuration for the remotes based on
the extra metadata present in the OSTree repo's summary file.
This parameter can still be combined with --title and --default-branch,
which take precedence when combined with --update.
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
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
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
We can't fetch the extra metadata from a repository's summary file before
having added it locally, since ostree_repo_remote_fetch_summary() will
fetch data by remote's name, and for that it needs to be added first.
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.
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 completely regressed, and it seems complicated to fix it without
requiring extra privileges. So, the new version requires you to sudo
to run it, which is not great, but at least it makes it work for
all cases.
This is nice because it guarantees that we get a new commit id
which fixes various issues we had with conflicting commit ids
overriding each others signatures.
Alexander Larsson