This is a pretty standalone object, and it is nicer to
have it in its own files. All users have been updated
to include the new flatpak-table-printer.h header.
The new `glnx_regfile_copy_bytes()` is better than the previous
`flatpak_copy_bytes()` in that it will use reflink/sendfile if available.
More information in 3a4d0f4684
After the introduction of linear progress reports based on
heuristics, Flatpak still couldn't make precise reports for
the extra-data field is contained in the commits. When we
were setting extra-data up, Flatpak didn't have the commits,
so it always failed.
Fix that by downloading the commits first, and then setting
up the extra-data fields.
flatpak/flatpak#609
Some previous g_set_error messages were related to 'unknown type', but this one about 'unknown location'. So it would probably be best to suggest 'valid locations', instead of 'valid types'.
The installed size in the metadata refers to the full
extension. If we have subpaths, the actual installed
size may be much smaller. Unfortunately, it appears
hard to obtain the actual size, so just hint at this
fact by displaying a '<' before the size.
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.