Save folks a few keystrokes. There is a command which already has a '-u'
option, document-export, but it doesn't support --user so there should
be no conflict. However '-s' is used by the info command among others,
so we can't use that for --system.
This makes it a lot easier to give guidance on using `flatpak run -d` or
`flatpak-coredumpctl`, because there's an easy way to install the
relevant refs.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
As discussed in #4848, this disables fuzzy matching when the string
given has a period in it. So for example "flatpak install org.mozilla"
would not offer "org.mozilla.firefox" even though the string given is a
substring of the app ID. This is desirable because it helps ensure fuzzy
matching is only used when the user intended to use it.
As with the previous commit that fixed#4829, this does technically
break backwards compatibility, but only in an interface intended for
interactive use by a human, not an interface that's used
programmatically, so it seems okay.
Previously, there were three different DTDs used. Let's switch to a single one.
We will go with 4.5, since it is latest version that does not have any backwards incompatible changes.
This allows you to ensure that a particular app/runtime is installed
and with the latest version in a single operation, which is useful
for instance in automatic use, like CI systems.
The gnome-apps repo is not being kept up to date so we don't want to
imply that people should use it, and make a few other tweaks to the
install command examples.
Closes: #2743
Approved by: matthiasclasen
Make synopses more concise in various place, improve
consistency of formatting, and fix some small mistakes
and oversights.
Closes: #2307
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
The --verbose and --ostree-verbose options are global to all
subcommands, but --version can only be used with the main "flatpak"
command, so fix the man pages to reflect that.
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
Some of these are grammatical errors, and some are mistakes caused by
copying phrases from the flatpak-install manpage.
Closes: #1177
Approved by: alexlarsson
This is a major change in the OCI support, as the format of the OCI image
registries changed. Instead of now having a "ref" file for each image
in the repo it has a single index json file, where the ref name is now
a per-image annotation.
This allows us to support OCI much better, as we can now use the actual
flatpak ref as the OCI ref name, and we can find all the flatpak refs
in a remote.
So, with this you can just use:
flatpak remote-add --oci remote-name URL
and then you can use the regular flatpak operations on the remote.
A few options aren't documented in the manpages. This commit adds
documentation for them based on the --help output and relevant commit
messages. Some of it could probably use more elaboration.
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.
- Fix typos in doc/flatpak-install and doc/flatpak-update.
- The commands ending in -app were deprecated in commit f7a1fdaa,
so update a few remaining references to them.
- flatpak-update is used for runtimes and applications, so fix its short
description.
Any "related" references from the same remote are automatically
handled when installing, unless you specify --no-related.
The set of related refs is based on the declared extensions for
the main ref. By default, all such extensions are automatically
installed/updated unless they have "no-autodownload" set to false
in the extension info, and its not already installed locally.
Only extensions marked as "autodelete" will be automatically deleted
when you remove the main ref.
There is some special handling:
Any *.Debug or *.Locale extension is automatically treated as "autodelete".
A *.Locale extension that is autodownloaded will be subsetted using subpaths
such that existing subpaths are kept, and the current locale is added.
