This early bailout is not really needed, because noop updates is
pretty fast. Also, doing that breaks the timestamp updates.
Closes: #1585
Approved by: alexlarsson
This fixes the ability of the remote-ls command to take a file:// URI
instead of a remote name, which is especially useful for repos on USB
drives (created via `ostree create-usb`) which are temporary and don't
warrant being added to the repo config. This commit also updates
relevant documentation, adds a unit test, and updates a few variable
names to improve readability.
I can't find a commit in the history where this was working, but it's
working on the Endless fork of flatpak so I think there was agreement at
some point that it's desired behavior.
Fixes https://github.com/flatpak/flatpak/issues/1588Closes: #1587
Approved by: mwleeds
When listing refs from remotes, a remote can be given by name or by URI.
This is an important distinction because dynamic remotes (USB/LAN) are
not internally mapped to a name, and thus their generated name cannot be
used for listing them. Thus, the solution is to use their URI in order
to list the refs directly from it.
Even though this feature has been around forever, the documentation
didn't really reflect it, so this patch mentions the described
alternative possibility.
Closes: #1587
Approved by: mwleeds
When listing refs installed or from a remote, only the refs matching the
main collection-id were being returned. However, it is very important to
have access to all refs, independently from their collection-id,
especially when trying to list remotes coming from a USB repository.
These changes add the mentioned refs and update the places that use
this list, both in the lib and in the CLI.
For the implementation to become easier, we introduce also a
FlatpakCollectionRef, that should be replaced by OstreeCollectionRef
once the latter becomes part of the general API (currently it is in the
experimental one).
Closes: #1587
Approved by: mwleeds
To implement this, we have a concept of a custom export filter
function which can be specified for each path to determine the
files that can be exported under that path.
Closes: #1589
Approved by: alexlarsson
This moves the prune call out of flatpak_dir_update() and
flatpak_dir_uninstall() and instead does this manually at all call
sites. The advantage is that we now only call it *once* even if you
uninstall or update multiple apps.
This means update everything is much faster as we don't have to scan
over the entire local repo for each updated app.
Reusing the summary and metadata here helps us a lot as typically we
often want to look up the cache data again for every ref in the list.
Closes: #1575
Approved by: alexlarsson
Until recently, "flatpak update --appstream" caused flatpak to only
update appstream data. Then commit 20c842012 accidentally made flatpak
also do a full update after updating appstream data, so this commit
fixes the regression.
Closes: #1571
Approved by: alexlarsson
This is a minimum viable implementation that just prints a warning.
A more comprehensive handling is possible, especially wrt the
rebase case.
Closes: #1566
Approved by: alexlarsson
This runs the app in a very tight sandbox, with no access to anything
except /app and /run and some read-only host things like fonts and icons.
You can additionally add explicit permissions on the commandline,
like --share=network to actually grant some access.
This also sets $FLATPAK_SANDBOX_DIR to ~/.var/app/$appid/sandbox in the
environment.
So, if you run your instance with e.g. flatpak run --filesystem=/some/dir
you can now see this. This will be useful in the restart yourself
portal as we can then inherit such permissions.
When uninstalling, if no specific installation was specified with e.g.
--user or --system, automatically chose any unique match, or error
out if there are multiple alternatives.
Fixes#1321
We currently auto-pick installation for update when you didn't pick
any specific one, so we should complete from all of them too.
Closes: #1537
Approved by: mwleeds
The remote-ls command should skip remotes that have "xa.disable" set to
true or have no URL set, which can happen for remotes added for flatpak
bundle files.
Fixes https://github.com/flatpak/flatpak/issues/1427Closes: #1457
Approved by: alexlarsson
If the --show-details option is passed to the remotes command, show the
collection ID for each remote, which the user might need to know if
they're using flatpak's P2P support.
Closes: #1458
Approved by: alexlarsson
This isn't needed for servers and starting the a11y bus on a
fresh session bus takes upwards of 15 seconds.
Fixes#1471Closes: #1486
Approved by: alexlarsson
Currently the search command only searches remotes for apps and runtimes
that match the host architecture. This commit makes flatpak include all
supported architectures so for example you can see a 32-bit app on a
64-bit computer.
Fixes https://github.com/flatpak/flatpak/issues/1353Closes: #1430
Approved by: alexlarsson
On atomic, /home is a symlink to /var/home, which caused
problems in flatpak build when granting access to the homedir.
Due to a previous workaround (in 1aadc3ee40) we
make /var in the flatpak build sandbox be completely overridden
with $builddir/var so that the above symlink would not cause problems
in the persisted directory.
However, when we actually *want* to give access to that symlink this
causes problem.
In general, exposing /var in the sandbox has two uses:
* Allowing persisting tmpfiles in /var/tmp between individual
flatpak build commands (/tmp is per-build-command).
* Creating flatpaks from packages, such as rpms, where
we want to keep the rpm database (/var/lib/rpm) around during
the entire build so that dependencies can be resolved.
In order to handle these /var/home issues while still allowing
the above issues we instead persist only /var/tmp and /var/lib.
Fixes https://github.com/flatpak/flatpak/issues/1407Closes: #1421
Approved by: alexlarsson
