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.
Tanu Kaskinen