Currently the update command only checks the default system and user
installations (unless overridden by a command line flag). This commit
makes it check custom installations as well, so they are not left out.
Care is taken so that an empty or broken installation doesn't cause the
whole update operation to fail.
Fixes https://github.com/flatpak/flatpak/issues/2006Closes: #2345
Approved by: matthiasclasen
Some commands depend on the first directory in the list returned by
flatpak_option_context_parse() being the default system directory, which
is true for FLATPAK_BUILTIN_FLAG_STANDARD_DIRS. This commit makes the
system directory first for FLATPAK_BUILTIN_FLAG_ALL_DIRS as well, in
case any code in the future uses that flag in combination with that
assumption.
There is one user of the ALL_DIRS flag that actually wants to keep the
user directory first in the list, the run command. This is so that a
user-installed app will be run even if the same app is installed
system-wide. So this commit modifies the run command to undo this
change after calling flatpak_option_context_parse().
Closes: #2345
Approved by: matthiasclasen
This lets us respect the fancy output setting, and
it lets us do some other things that make it better
integrated.
Closes: #2379
Approved by: alexlarsson
Arrange for progress to be done before we
ask for polkit auth, so we don't end up with
the text prompt mushed into the progress display.
Closes: #2379
Approved by: alexlarsson
Install a polkit text agent that can ask for
authorization when we are on the console.
This brings us closer to best practice for polkit use.
Closes: #2379
Approved by: alexlarsson
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
Currently if you don't specify a remote to the install command, it might
suggest that you use an origin remote like "org.gnome.Builder-origin"
which doesn't make much sense since those are tightly tied to the app
installed via bundle that created them. So this commit respects the
"xa.noenumerate" flag that is set on such remotes, so they aren't
searched for refs.
Closes: #2376
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
When --delete-data is passed when uninstalling an app,
remove its app data directory in ~/.var/app/. When
--delete-data is used without a ref, remove all 'unowned'
app data directories.
Closes: #2314
Approved by: matthiasclasen
This is currently only used in the ‘search’ built-in command, but will
need to be used in upcoming parental controls filtering changes in
Endless OS (which will go upstream eventually) too.
This introduces no functional changes.
The CFLAGS/LIBADD changes are necessary because of the new
AppStream #includes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #2296
Approved by: matthiasclasen
And hence provide at least a little bit of hope that this doesn’t become
permanent technical debt.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #2296
Approved by: matthiasclasen
This commit implements a feature in the multiple choice prompt that
mirrors the behavior in the yes/no prompt where it can default to "yes"
when the user only presses Enter. In the case of the multiple choice
prompt, it only defaults to the first choice on Enter if there's only
one option (e.g. you're asked if you want to install from the "flathub"
remote as opposed to being asked to choose between the "flathub" and
"eos-apps" remotes).
This feature can be turned off on a per-prompt basis if we want explicit
user input for something but I didn't find that necessary for any of the
existing prompts.
Also note that as with the yes/no prompt defaulting to yes on Enter,
this only applies for interactive terminals. If Flatpak is being run by
a script no choice will be made automatically.
This should save users unnecessary keystrokes, such as when they use
"flatpak install devhelp" and are asked to confirm that the Flathub
remote is the one to use (now they can just press Enter).
Closes: #2288
Approved by: matthiasclasen
Currently when the install command has to prompt the user to resolve
ambiguity over which ref to install, the prompt only mentions the
(partial) ref that was specified. If a remote was specified or the user
chose one in a prompt, this is probably fine. But if the user didn't
specify a remote and used the --assumeyes/-y option so that one would be
chosen for them, there's no way to tell which remote is being used at
the point when the ref ambiguity is being resolved. So this commit adds
information about the remote name and flatpak installation to the
"Similar refs found" prompt.
Closes: #2288
Approved by: matthiasclasen
Currently if the user doesn't specify a remote name to the install
command, Flatpak chooses the first one that has a matching ref, either
with or without user interaction depending on whether --assumeyes/-y was
used. Then if more than one remote ref is similar to the one specified,
the user is prompted to choose between them. I think this asymmetry
doesn't make much sense; why not have the user choose between remotes
just as they choose between refs?
For example, the string "libre" matches refs from both flathub and
eos-apps, so if I do "flatpak install -y libre" a remote is arbitrarily
chosen for me but I'm still prompted to choose between the refs (since
-y can't choose for you when there are mutliple choices).
So this commit changes the install command implementation to present the
user with a list of remotes that have matching refs all at once rather
than one at a time. The reason I didn't implement it this way at first
is that I was worried about the performance impact, but in testing I'm
not able to measure a difference between stopping at the first remote
with a match and checking every remote (although the story might be
different if you have many remotes or don't have up-to-date metadata
downloaded).
If there's an error searching a remote, it's treated as a warning so
that one misconfigured remote doesn't take down the whole operation with
it.
This commit also updates the unit tests so they continue to succeed.
Closes: #2288
Approved by: matthiasclasen
This commit changes the struct "RemoteDirPair" to "RemoteStateDirPair"
so that an upcoming commit can make another struct called
"RemoteDirPair" in flatpak-builtins-utils.[ch] which will just have the
remote name and dir without a state. This commit also removes the
"remote_name" member, because it makes more sense to use the remote_name
field in the state object.
Closes: #2288
Approved by: matthiasclasen
Put brackets around the "LOCATION/REMOTE" argument to the install
command, because the remote name is now optional. It's difficult to
summarize all the forms supported by the command in one line, but this
seems more accurate than it was before.
Closes: #2288
Approved by: matthiasclasen
Currently when the Flatpak command line prompts the user with a yes or
no question, the user must type "y" or "n" to respond. This commit
changes it so that the prompt can assume "yes" if the user just presses
Enter. In that case the prompt ends in "[Y/n]" rather than "[y/n]". If
there are some operations that are considered dangerous, we can still
require explicit user input on those, but as far as I can tell those
criteria don't apply to any existing prompts.
This behavior of allowing the user to just press Enter is consistent
with how apt works for example.
Note that this is distinct from the "--assume-yes" option we have, since
that won't prompt the user at all when a decision needs to be made.
Closes: #2113
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
This moves the implementation of the Levenshtein "edit distance"
algorithm from app/ to common/ so it can be used in an upcoming commit.
Closes: #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
If some installation is empty (or otherwise broken) we fail the
entire run command, even though the app might exist in e.g. the
user installation. This is a regression from
651c86d3c6 which also ended up in 1.0.4.
The test for --columns was failing in ci because flatpak
gets built without libsystemd there. Avoid this by always
handling --columns=help nicely, even if libsystemd is not
used.
Closes: #2244
Approved by: alexlarsson
In this case, the columns helper function returns an
empty array of columns. Exit cleanly without trying
to contact the documents service, in this case.
Found while writing tests.
Closes: #2244
Approved by: alexlarsson
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
Don't show the full --help output immediately, instead
say 'see flatpak --help' and make a suggestion for a
misspelt command.
Closes: #2209
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
