Rename permission-list and document-list to
permissions and documents, for consistency with
how we handle remotes. The old command names
are kept as hidden aliases.
Closes: #2131Closes: #2366
Approved by: mwleeds
Make it clear that the command can be used a few different ways, and the
option used determines the needed positional arguments.
Closes: #2361
Approved by: matthiasclasen
This adds support for fuzzy matching ref names (AKA "typo helper") to
the uninstall command to mirror what the install command has. In short,
this means you can do "flatpak uninstall gedit" instead of "flatpak
uninstall org.gnome.gedit". Flatpak will prompt you to choose between
similarly named installed refs, and will only make the choice for you if
--assumeyes was used and there's only one match.
Note that this commit does have the side effect that if there are
multiple matching refs with the same ID (e.g. with different branches or
in different installations) you are prompted to choose between them.
Previously you were shown an error message.
Closes: #2330
Approved by: matthiasclasen
This commit adds a key called DeployCollectionID to the flatpakref and
flatpakrepo file formats, which is intended to replace the CollectionID
key (which is still supported but deprecated). The reason for the change
is the same as for the metadata key change from xa.collection-id to
ostree.deploy-collection-id, which is that old versions of Flatpak
(roughly 0.9.8 through 1.0.1 depending on compile time options) hit
various bugs when collection IDs are in use. Flathub will soon enable
the metadata key to deploy collection IDs, and this change means Flathub
can also deploy the collection ID in flatpakref and flatpakrepo files
without affecting old clients.
Adding DeployCollectionID to the flatpakref and flatpakrepo files will
mean the flathub remote can be automatically configured with a
collection ID without depending on the metadata key to do that.
Closes: #2329
Approved by: alexlarsson
Make synopses more concise in various place, improve
consistency of formatting, and fix some small mistakes
and oversights.
Closes: #2307
Approved by: matthiasclasen
A convenience wrapper around ostree_repo_get_min_free_space_bytes().
Clients programs like gnome-software can get the value of minimum free
space as defined in the OSTree repo. This can be useful in various
disk-space checks these client program can implement.
At Endless, we have downstream heuristics in gnome-software which
determine the success/failure likelihood of an install/update
operation to some extend. Depending upon the likelihood of the
success/failure we dispatch install/update/auto-update operations.
With client programs gaining features such as auto-updates, it makes
sense to have a min-free-space API so that these programs can check
free-space availablity vs minimum free space defined by user inside
OSTree's repo before auto-updating. Although, OSTree will certainly
fail operations over-stepping min-free-space's value; It's just a
matter of convenience to provide a way to query the value to client
programs as well.
Closes: #2274
Approved by: matthiasclasen
Currently the install command requires the user to specify the remote
name in addition to each ref that is to be installed. This commit
implements an auto-detection feature so that the user can specify only
refs (or partial refs) and Flatpak will try to determine the remote to
use.
The Flatpak security model does not consider all remotes equally
trustworthy, but that's okay because the user is asked to confirm the
remote choice before it's used.
The way it's implemented is that we look at only the first ref (even if
there are several) and iterate through each remote in each installation
trying to find it, stopping at the first one where it's found and asking
for confirmation of it. There's a trade-off here between efficiency and
accuracy, since it could be pretty costly to search every remote in
every installation. I think this should be good enough for most use
cases, and the user is still free to specify a remote and avoid that
code path.
This should hopefully save people a bit of typing and make the Flatpak
CLI a bit friendlier.
Closes: #2113
Approved by: matthiasclasen
This commit implements a "typo helper" for the install command, so that
if you don't get the app ID exactly correct you're prompted with
similarly named apps available in the remote that you can choose from.
Essentially this allows you to do "flatpak install flathub devhelp"
instead of "flatpak install flathub org.gnome.Devhelp".
The choice is only made for you in two cases: 1. If it's an exact match
and there's only one match, it is used as before this commit. 2. If the
-y/--assume-yes option was used and there's only one match, it is used.
Presumably scripts would always specify the full app ID, so this should
only affect users on the command line who choose to use that option.
In the future we may want to use the groundwork laid in this commit to
add similar functionality to other commands, like perhaps remote-info
and run.
This is a partial fix for https://github.com/flatpak/flatpak/issues/1258Closes: #2113
Approved by: matthiasclasen
Avoid the 3-second 'afterlife' of instances by using
kill (pid, 0) instead of checking the file lock. We
trade pid for lock races, but this seems more reliable.
Also add flatpak_installation_launch_full that returns
a FlatpakInstance for the launched app, and lets us
avoid races around killing the app, by using a child
watch.
Closes: #2221
Approved by: matthiasclasen
The history command pulls the transaction log entries
out of the journal, and presents them nicely.
We use the sd-journal api for this, so we need to
link against libsystemd now, but we make the dependency
optional. If libsystemd is not available, the history
command will simply print an error.
In version 0.99.1 (065053775b) flatpak
stopped inheriting permissions from the runtime, because that made
the story about application permissions way to complicated. What
we want is to have a static set of permissions for the app that
is frozen at install time.
However, inheriting permissions from the runtime makes a lot of sense
as certain permissions are required from the runtime, in particular this
is used by the kde runtime to read the kdeglobals file, etc.
So, to combine the best of the two worlds, we now do inherit permissions,
but at build-time (and you can disable it if you want). This way
kde apps don't have to repeat themselves, but we still get static
application permissions.
Closes: #2230
Approved by: alexlarsson
When I decided to add --columns without --show-columns,
I remove the option everywhere. Almost. These are the
leftovers I forgot.
Closes: #2227
Approved by: alexlarsson
Add a runtime column that shows the runtime an application
is using, and add an --app-runtime option to allow filtering
by the used runtime.
Closes: #2224
Approved by: alexlarsson
With the instance infrastructure, we can go from
the ID of a running application to its monitor PID,
so we can accept the application ID here. Whats more,
we can offer completion for it.
Note that completion only works if you use sudo -E,
since the flatpak used for complcations needs to see
the session environment to find running instances.
Closes: #2181
Approved by: alexlarsson
This sends SIGKILL to a running sandbox process.
The command has completion for running applications,
for both application IDs and instance IDs.
Closes: #2180Closes: #2181
Approved by: alexlarsson
This lets you use list --app --app-runtime=org.gnome.Platform//3.24
to see which apps on your system still depend on this old runtime.
Closes: #2175
Approved by: alexlarsson
Mention how flatpak run handles environment variables,
and include the blacklist of variables we always override.
Closes: #2141
Approved by: alexlarsson
This option shows the contents of an override file. If an appid
is given, it shows overrides for that app, otherwise
the global overrides.
Closes: #2041
Approved by: alexlarsson
This option removes an override file. If an appid
is given, it removes overrides for that app, otherwise
the global overrides.
Closes: #2041
Approved by: alexlarsson
