This is a method to explicitly prune the local repo, which
users might want to use if they had explicitly removed refs from
the underlying flatpak repo and want to ensure that the objects
referred to by those refs are cleared to save on disk space.
Closes: #1034
Approved by: alexlarsson
We might want to prune the repo from within the library or
the command line and may not be in a privileged context, so
we'll need to jump through the system helper to prune the refs.
Closes: #1034
Approved by: alexlarsson
It might be more efficient to perform this operation at the end of
removing a batch of refs, so perform it there instead.
Closes: #1034
Approved by: alexlarsson
In some cases, we want to include the repo part of the refspec,
for instance, if we are to pass refs directly to flatpak_dir_remove_ref
Closes: #1034
Approved by: alexlarsson
In some cases, a user might pull a ref into the local repository and
not deploy it by using FLATPAK_INSTALL_FLAGS_NO_DEPLOY. Later on, that
user might decide that they don't want to deploy the ref after all,
but there was no way to remove that ref from the local repository
in the public API, so it takes up disk space.
Add flatpak_installation_remove_local_ref_sync to remove a given
ref from the local repository if the ref is known and
flatpak_installation_cleanup_local_refs_sync to remove all undeployed
refs.
Fixes#1031Closes: #1034
Approved by: alexlarsson
A few fixes worth having, also just testing Homu.
```
Colin Walters (2):
fdio: Open target dirname for glnx_file_copy_at()
lockfile: Use an `initialized` member rather than explicit init
Jonathan Lebon (1):
macros: use size_t for glnx_strjoina len
Philip Withnall (1):
shutil: Fix assertion failure in glnx_shutil_mkdir_p_at()
```
Closes: #1046
Approved by: alexlarsson
The kernel used on some autobuilders for the Debian PA-RISC port
can do "bwrap --ro-bind / / /bin/true", but not the bwrap invocations
made during the actual testing, which fail with "Creating new namespace
failed: Invalid argument". Make the trial bwrap invocation more like
what Flatpak actually does, so that these tests will hopefully be
skipped on such kernels.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876743
Signed-off-by: Simon McVittie <smcv@debian.org>
We used to only expose symlinks if the path to one was explicitly exposed,
like --filesystem=/symlink, but if you did say --filesystem=/symlink/dir, then
we would make /symlink be a regular directory in the sandbox tmpfs.
This means all exports are fully resolved, which allows use to remove the
workaround for symlinks that we had with sorting by "level".
We also add a FAKE_MODE_DIR, which is used to ensure the homedir is there,
created on tmpfs if needed only, while handling symlinks correctly.
This means that flatpak works well even if $HOME is on a symlink.
If the target of a direct bind, such as $home/.var/app/$appid/ is
a symlink, and the symlink contains absolute pathnames, then they
will not resolve correctly in the bwrap setup code due to the
fact that the final root is on /newroot, not /, so we resolve
the target paths before we call bwrap.
When we're resolving a symlink to see if the destination is visible, then
we have to actually append the rest of the path to look at the final
target, not just the intermediate symlinked directory.
When we hide a directory like that and it is a symlink we need
to hide the symlink target. Additionally, when we're checking
whether we need to mount the tmpfs we need to check that the
target is an actual dir, rather than a symlink to a dir.
Fixes https://github.com/flatpak/flatpak/issues/1032
This is taken in exclusive mode whenever we prune the repo. Anything
that is not protected against object disappearing from the repo can
take the lock in a shared mode to avoid running at the same
time as a prune operation.
The two operations the are problematic in this respect is
Pull:
* During the pull we see that some object we require is already available
and doesn't need downloading. We can't have it be removed before we
commit the transaction.
* During the transaction commit we're moving the object to the
repo, and they risk being pruned as unreachable until we have updated
the ref.
Deploy:
* Once we start checking out a particular ref we assume all the object
from it is reachable. If the ref is updated in parallel some object
can become unreachable and removed.
So, we take shared locks in these operations.
In the prune operation we take the block non-blocking, and skip
the prune entirely if some other operation is outstanding, because
we don't want to block a long time, and its likely that due to the other
operation we will run prune shortly anyway.
Note: Nothing protects the system-helper case when we download to a separate
repo. However, if there is a race we will get an error when importing this
to the system repo, so we'll never end up in an inconsistent state.
There are some changes needed to who automatic installation from OCI
repositories work that need to happen in the future. In order to not
"break" this support in a future stable release, we disable the adding
of oci repos unless the FLATPAK_ENABLE_EXPERIMENTAL_OCI environment
variable is set.
There is an important rofiles-fuse fix in this that
really mainly affects flatpak-builder, but we might as well
require it for flatpak too, so that we're sync:ed on the dependencies.
This is useful for Flatpak runtime and app authors who want to know
which features they can use when targeting a particular branch,
or if they do not have a particular branch in mind, what value they
should put in the required-flatpak field.
Signed-off-by: Simon McVittie <smcv@collabora.com>
