We need to know if we're forwarding uris or files, because
if we're doing uris we need to pass on non-file uris as-is.
So, we enclose uris with "@@u @@" instead.
This also properly (un)escapes the file uris
The --app and --runtime options are not really useful
for flatpak info, since you need to specify a full ID
anyway, and it is highly unlikely that you will have
ID clashes between apps and runtimes. Also, the options
are documented in a confusing way.
If branch is unset this is just a nicer way to set a
particular commit. However if both are set, then we verify
that the branch/tag is at that particular commit. This is
a nice way to document that we want to use a particular tag
but still protect against the tag changing or a MITM attack
modifying what that tag means.
Instead of one mega flatpak-builder man page, move the
file format documnentation to its own man page in the
right section, and shorten the flatpak-builder one.
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.
For a few commands the options aren't fully documented. This commit
makes the manpage documentation (almost) match the options shown
when you run "<command> --help" on the command line.
This is useful for modules that don't have a make install rule.
You can use the new build-commands which is run after make to
create your own custom installation phase.
Fixes https://github.com/flatpak/flatpak/issues/458
The ability to use flatpak-run to enter into a shell in a runtime was
added in flatpak 0.6.13 but the docs weren't updated to reflect that.
This commit updates the flatpak-run documentation to explain the
functionality.
This lets you skip rebuilds unless the actual json changes.
This is useful for continuos builds that only run if the json
changes, not on any commit to any git source.
Instead of building directly into the app directory we build into a
rofiles-fuse mount of it, which allows us to safely check out the
cache into the app directory using hardlinks (because rofiles-fuse
will not let you modify hardlinked files).
Additionally, every time we commit to the cache we check out all
the new and modified files into the appdir so that we get hardlinks
to the repo for the new files too.
The advantage of having hardlinks to the repo is that we can commit
much more efficient since we don't have to do a full checksum of
the hardlinked files.
There are some issues here:
eu-strip fails due to doing in-place editin
rofiles-fuse is using lots of CPU, unclear if this is faster, needs
measurements
needs testing of how well the fallback works (ie. if fuse is not
working).
rofuse: use kernel caches
rofiles: check out after commit
Use devino cache
Only check out new files from cache after commit
Rebuilding all apps because a minor change in the runtime is way too wasteful
and generated unnecessary app updates, especially since runtimes are supposed
to be API stable.
We add an a --rebuild-on-sdk-change option which you use to disable this feature,
for instance if you're building against an unstable SDK.
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.
Not being documented makes it hard to know that this actually
takes the url of a flatpakrepo file, as opposed to the other url
key in this file, which takes the url to a remote.
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.
Currently flatpak-builder downloads the sources for all modules, even if
the --stop-at option prevents them from being built. This commit changes
the behavior so that we don't bother to download the ignored modules.
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.
When initializing a build you can initialize the application directory
with the files from another directory, and optionally a set of its
extensions. This allows one to create a "base" application that
can be derived from in multiple forms. A typical example is an application
framework like Electron. The base electron app has all the dependencies
needed to write Electron app, and then your manifest can add the specific
files needed for your application.
An example snipped could look something like:
"base": "org.base.App",
"base-version": "stable",
"base-extensions": ["org.base.app.Locale", "org.base.app.Debug" ],
The --allow-missing-runtimes options will allow flatpak builder to
not abort immediately if the sdk or runtime for the app being built
are missing.
This option will be useless when building anything in the modules
section of the app manifest. The calls to flatpak-build will fail
because of the missing sdk.
However, it may be useful when an application does not require
building anything inside the sandbox, and the application files
will be installed via other means.
Provides access to the functionality offered by the new internal API
flatpak_dir_update_remote_configuration(), in a similar way to what
can be done via the command 'flatpak remote-modify --update-metadata'.
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.
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.
This adds a new "multiarch" feature which allows bundling e.g. 32-bit
binaries to be run in a x86_64 environment. By default, the seccomp
filter is configured to allow only the native architecture. When the
"multiarch" feature is enabled, the filter will be configured to allow
running binaries of additional architectures supported. For x86_64, this
allows x86 32-bit binaries; and for Aarch64, allows 32-bit ARM binaries.
Application bundles can use the feature e.g. in order to ship 32-bit
binaries alongside with a mostly-64-bit application. This is particularly
interesting when for applications that might launch themselves prebuilt
programs for which 64-bit versions do not exist. For example, the Steam
application is available as a 64-bit executable, but some of the games
available are 32-bit only. A Flatpak bundle for the Steam application
with "multiarch" enabled is able launch the 32-bit games -- without the
feature enabled, the seccomp filter would prevent them from running.
Multiple-architecture support is enabled by adding the "multiarch" value
for the "features" key in the metadata file for a Flatpak:
[Context]
features=multiarch;
The corresponding "--allow=multiarch" command line option is supported
in "flatpak build-finish" as well.
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 no longer needed, as we don't hard-require systemd --user.
We keep the opion there, but hidden in order to be backwards compatible
with old code that used this.
This enables support for ptrace and perf for the app, similar
to what run -d manually gave you before. This is nice to be
able to package an app like gnome-software.
This disables build-args support, which is nice when building things
on e.g. a shared build-machine, where we don't want the build to
be able to break out of the sandbox (by specifying e.g. --share=network).
Stop building at a specified module from the json file.
This is useful during development. For instance, you can do --stop-at=main-app
to build all the dependencies into the appdir, then you can do a build of an
already checked out git repo (possibly with changes).
- 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.
Currently to use a local copy of a git repo you have to specify the url
as "file:///path/to/repo". This commit allows you to specify a path directly
as "/path/to/repo", which is faster and more space-efficient because
git-clone will hardlink the objects rather than copying them.
Some of the options do not explicitly say they can be used multiple
times even though it's clear from the code that they can. This commit
fixes that by saying so in the manpages.
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.
I don't think it makes sense to have to enable this for everything.
It should be safe in the sense that you can't ever do more than
the user can do anyway, and there is no way to use this to communicate
with the rest of the system because you can't read from it.
The worst this could ever cause is to overload the system, but the
sandbox doesn't protect against that in any other way anyway.
Alexander Larsson