Set autodelete=true on locale and debug extensions.
Set no-autodownload=true on debug extensions.
Thats what will happen anyway, but its nice to be explicit.
Also, remove subdirectories=true on the locale extensions, as
we're not using that anymore.
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.
This lets us find all the "related" refs to a ref in a particular
remote, or locally. These are the things we should automatically
download or delete when installing/updating/uninstalling the ref.
The implementation currently looks at all the extensions handled by the
app/runtime. For debug extensions and extensions marked no-autodownload we
only consider them related if its already locally installed. For locale
extensions we always consider them related, but we only pull the current
locale data for it.
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.
One of the variations tested on Debian's reproducible build
infrastructure is that the second build is done in a French locale.
This test fails there, because it doesn't see "Usage:" in the help.
Signed-off-by: Simon McVittie <smcv@debian.org>
This lets distributors share a system copy of bubblewrap (>= 0.1.0)
between Flatpak and any other projects that benefit from it, if they are
careful to keep new versions in sync. The default is still to use the
bundled submodule, ensuring compatibility and simplifying dependencies.
Enable $PATH search everywhere that runs bwrap, so that $BWRAP doesn't
necessarily need to be a fully-qualified path.
Signed-off-by: Simon McVittie <smcv@debian.org>
Otherwise, service activation will start a new xdg-document-portal
(because we're using a private DBUS_SESSION_BUS_ADDRESS), but because
XDG_RUNTIME_DIR is shared with the real system, it won't be able to
mount its filesystem.
We need to unmount the document portal before removing the private
XDG_RUNTIME_DIR.
Signed-off-by: Simon McVittie <smcv@debian.org>
We shouldn't install .test metadata for these, and run them as TAP
test scripts. In glib-tap.mk jargon that makes them "extra scripts".
Signed-off-by: Simon McVittie <smcv@debian.org>
As soon as we get our D-Bus name, we can start receiving method calls. If
we reply immediately, callers will think our mount point is ready.
In particular, if FUSE is unavailable, we want "flatpak run" to proceed
with no document portal; it currently tries and fails to bind-mount the
nonexistent document portal mount-point into the container.
Signed-off-by: Simon McVittie <smcv@debian.org>
