This creates a $flatpakdir/exports/bin directory that contains wrappers
for all active installed applications, named by the application id.
If you add these directories to you $PATH, then this means you can more
easily launch flatpak apps on the commandline.
Closes: #1254
Approved by: alexlarsson
It doesn't really make sense for a runtime to export anything, so
lets just enforce that. Note, this is not necessary a security
issue, because anything exported from runtimes were rewritten
just like apps. It just enforces the expected behaviour of
runtimes.
Closes: #1254
Approved by: alexlarsson
The test used to verify that metadata was coming from the
ostree-metadata ref rather than the summary file, by ensuring that
xa.title was set in one but not the other, by regenerating one
separately from the other. However, since the test was written, OSTree
has changed so that it now writes them both out, at the same time, with
no possibility of separating the two.
Trim down this test so it no longer tries to check the source of the
updated metadata, and instead just checks that it is updated.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1201
Approved by: alexlarsson
If the remote is a local path (absolute or relative starting with ./)
then we convert this to a file: uri, which are now supported to
install directly from a local repo.
This is very useful when testing locally built apps.
Closes: #1244
Approved by: alexlarsson
If you're installing something and its already installed, we undeploy
the old install first before deploying the new. This makes it very
easy to switch an application from one remote to another, without
having to uninstall first, which is both painful and could cause
the download to be unnecessary large.
Closes: #1241
Approved by: alexlarsson
This lets you add overrides that affect all applications. Application
overrides have higher priority so will override the global overrides.
Closes: #1245
Approved by: alexlarsson
This means that if you e.g. do
flatpak run --filesystem=home --nofilesystem=~/foo
Then /.flatpak-info will contain:
filesystems=home;!~/foo
This also makes overrides with --nofilesystem work,
fixing https://github.com/flatpak/flatpak/issues/1232Closes: #1245
Approved by: alexlarsson
Currently --nofilesystem just means that we undo a similar --filesystem,
so --filesystem=~/foo/bar --nofilesystem=~/foo/bar means we can access foo.
If you did --filesystem=~/foo --nofilesystem=~/foo/bar then the later
would have no effect.
We now handle this by giving access to foo, but hiding bar beneath it.
Closes: #1245
Approved by: alexlarsson
This is a no-op on regular (archive) repos, but on bare repos it is
an optimization if the source is a checkout from the repo. This
happens in flatpak-builder (https://github.com/flatpak/flatpak-builder/pull/81)
when it commits the build to the cache during --install without --repo.
Closes: #1249
Approved by: alexlarsson
Now that flatpak update does both per-user and systemwide
per default it makes a lot of sense to say which one is being
updated.
Closes: #1248
Approved by: alexlarsson
I got weird crashes in the local repo pull case where the default
progress reporting callback tried to get some unset key on
the progress. We don't want any progress reporting anyway, so fix
this by dropping all progress reporting.
Closes: #1243
Approved by: alexlarsson
I got this:
app/flatpak-main.c:364:20: warning: variable 'dir' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
else if (opt_installations != NULL)
^~~~~~~~~~~~~~~~~~~~~~~~~
app/flatpak-main.c:374:34: note: uninitialized use occurs here
g_ptr_array_add (dirs, dir);
^~~
app/flatpak-main.c:364:16: note: remove the 'if' if its condition is always true
else if (opt_installations != NULL)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
app/flatpak-main.c:358:26: note: initialize the variable 'dir' to silence this warning
FlatpakDir *dir;
^
= NULL
However, that is never hit, its just the compiler being confuses, so we add a
g_assert_not_reached() in the last else case.
Reachability analysis:
If opt_installations is != NULL we will at the very least take the
last if, and if opt_installations == NULL, we will take the first one
if !opt_user, and the second if opt_user.
Closes: #1251
Approved by: alexlarsson
Now that flatpak_resolve_duplicate_remotes checks if a remote exists, we
don't need to use ostree_repo_remote_get_url to do so. This commit
doesn't change the behavior for remotes with empty URLs (which means
they're disabled), because the empty string is an allowed value as far
as OSTree is concerned.
Closes: #1247
Approved by: alexlarsson
We should use the same flags for the flatpak_option_context_parse() call
in flatpak_complete_list_remotes as we do in
flatpak_builtin_list_remotes, so the options are parsed correctly.
Closes: #1205
Approved by: alexlarsson
Currently "flatpak remotes" shows remotes across user and system
installations, but other remote commands (remote-delete, remote-modify,
remote-ls, remote-info) only work on one installation: the system one
unless overridden using --user or --installation. This commit changes
each command to infer the correct installation by checking which has
the specified remote. In case multiple installations have remotes by
the same name, the user is prompted to decide which to use.
This commit also adds unit tests and updates the man pages for the
aforementioned commands.
Fixes https://github.com/flatpak/flatpak/issues/787Closes: #1205
Approved by: alexlarsson
Some builtin flatpak commands work on a single installation, and others
work on multiple installations (such as the remotes command that lists
both system and user remotes). Currently flatpak_option_context_parse()
only supports returning one installation to its caller, and any commands
that want to support multiple installations have to implement that
themselves which leads to a lot of code duplication.
This commit changes flatpak_option_context_parse() to take three new
flags:
* FLATPAK_BUILTIN_FLAG_ONE_DIR maintains the old behavior by
returning one installation (i.e. user if --user was passed, system if
--system, etc.).
* FLATPAK_BUILTIN_FLAG_STANDARD_DIRS will get all the installations
specified by the options, or the user and system ones if none were.
* FLATPAK_BUILTIN_FLAG_ALL_DIRS includes non-default system
installations along with the user and system ones if none were
specified.
These flags also affect what options are parsed and whether the
directories are ensured to exist, so it makes sense in some
circumstances for callers to pass a NULL out_dirs even when not using
FLATPAK_BUILTIN_FLAG_NO_DIR.
This commit also changes all the callers of
flatpak_option_context_parse() so they maintain their behavior. The only
functional change introduced by this is that using --installation
multiple times for commands that only support one now leads to an
error emitted by flatpak rather than by g_option_context_parse().
A follow-up commit will use this refactoring to make many commands
behave more intelligently in determining which installation to use.
Closes: #1205
Approved by: alexlarsson
We regressed on supporting --filesystem=xdg-config/kdeglobals:ro which
would create a "kdeglobals" in the apps own XDG_CONFIG_DIR which has
content from the host one. This broke in
f1df5cb1d9
where we added a symlink resolve, but that breaks when the target file
doesn't exist.
It seems like all callers rely on just the final element of the destination
path being created, so lets just resolve symlinks on the dir part.
Closes: #1229
Approved by: alexlarsson
The "flatpak remote-ls" command can be used without specifying a remote,
so change the man page and --help output to reflect that.
Closes: #1210
Approved by: alexlarsson
This means flatpak can bootstrap itself from an empty /var on stateless
systems, which fixes https://github.com/flatpak/flatpak/issues/113, at
least for the CLI case.
Closes: #1195
Approved by: alexlarsson
This replaces the old unused FLATPAK_BUILTIN_FLAG_NO_REPO with a
version that tries to init the repo, but doesn't fail otherwise.
Also, we drop the explicit flatpak_dir_ensure_path() call, because
flatpak_dir_ensure_repo() calls that anyway.
Closes: #1195
Approved by: alexlarsson
