Never check out directly from the cached dir, instead always
create a .flatpak-builder/bzr/ directory we can later
update from by branching from the cache and then rewriting
the parent location.
We always have a local git checkout in .flatpak-builder/git
so that we can later update in it. However, if --extra-sources
is used and the git repo exists there, we use the data there
to clone the initial repo, to avoid lots of traffic on the network.
Additionally, if --disable-update is specified we just straight
clone the local cache repo, and then rewrite the origin to the
real one. This means we never do any network i/o to the original
pull.
Instead of mixing the source bundling with the build we make
it a separate step at the end, with cache support just like the
other stages.
Being at the end means we can reuse the cached stages from the
build if we enable bundle-sources after an existing build.
Also, this changes how the json and local files/patches are stored.
Now they are in a subdirectory called "manifest" in the sources
directory, with proper handling of relative pathnames for included
modules, etc. This also means we don't look for these file in the
extra-sources directory, but rather next to the json like we
do normally.
My understanding is that rofiles-fuse is just an optimization,
and we support building without it anyway (using --disable-rofiles-fuse).
So, instead of failing the build, we can just not use rofiles-fuse
if it is not present on the system, which seems to be the case on
some OSes, we've seen this reported from Debian and Arch.
For now, this just prints bits of summary information in
human-readable form. This command could grow over time
to provide other functionality for managing local repositories.
Show the same data the we show for other refs, when we
list extensions. In addition, show the subpaths if there
are any. Note that this reveals that the installed size
for subpath'ed extensions is misleading, since it is
the installed size for the full extension.
I have multiple branches of org.gnome.Platform install system-wide,
and non per-user. And flatpak info gives me:
flatpak info org.gnome.Platform
-> not installed
flatpak info --system org.gnome.Platform
-> multiple branches
This confusing behavior comes from the fact that we are querying
multiple locations and are not careful enough to collate the
errors we get properly. This commit changes things so that we
keep querying the next location as long as we get a 'not installed'
error, and we report the first 'multiple branches' error we get.
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.
