This moves the triggers from out of flatpak_install/update/uninstall
and instead calls them manually at all the sites that call this.
This allows FlatpakTransaction to only run the triggers once for the
entire operation.
Closes: #1743
Approved by: alexlarsson
In the no-pull case and when uninstalling, we never want to do any network
i/o for e.g. detecting depenedencies.
Closes: #1744
Approved by: alexlarsson
This does no network i/o and just keeps track of remote name
and collection id. This can be used for no-pull transactions.
Closes: #1744
Approved by: alexlarsson
This reads the current commit for a ref in the local repo.
This can be used e.g. to get at the metadata for an already pulled ref.
Closes: #1744
Approved by: alexlarsson
This is the same as flatpak_dir_search_for_dependency, but it looks only in the local
repo for already pulled dependencies. This is useful if you're in no-pull mode.
Closes: #1744
Approved by: alexlarsson
This makes info, list, remotes, and search work if there is no
system flatpak repo. Before it failed with EPERM.
Closes: #1742
Approved by: alexlarsson
This is a fsck-like command that tries to automatically repair your
flatpak installations. It works by running an fsck on all the refs in
the local repo, and removing all refs that has an unexpectedly missing
(or deleted) object.
Then it runs a prune, which will remove all the object that were
referenced by these removed refs (that were not references by anything
else), so that any non-detected invalid objects are also removed.
Then it looks at all the deployed refs, and if they lack a ref in
the local repo, we `install --reinstall $origin $ref` them.
Closes: #1739
Approved by: alexlarsson
I was getting this:
annobin: Flatpak_1.0.c: Error: plugin built for compiler version (8.0.1) but run with compiler version (8.1.1)
cc1: error: fail to initialize plugin /usr/lib/gcc/x86_64-redhat-linux/8/plugin/annobin.so
Closes: #1741
Approved by: alexlarsson
In the Fedora 28 base container, `coreutils-single` is used and so
`/usr/bin/ls` is actually a "script":
```
$ file /usr/bin/ls
/usr/bin/ls: a /usr/bin/coreutils --coreutils-prog-shebang=ls script, ASCII text executable
```
We handle this by detecting shebangs in dependencies and recursively adding them.
Closes: #1741
Approved by: alexlarsson
ostree 2018.6 will make the P2P API public that was previously
experimental, and add a "p2p" feature flag to replace "experimental". So
this commit updates the logic in flatpak's configure.ac so that we check
for either feature flag and only define OSTREE_ENABLE_EXPERIMENTAL_API
if necessary. This way we can do the right thing against development
builds of 2018.6 that might not have the P2P API public yet.
This commit also changes the behavior when flatpak is built against
ostree < 2018.6. Specifically, P2P support is enabled if and only if
we're building against an ostree that has the relevant API, rather than
depending on the user to use `--enable-p2p` or `--disable-p2p`. This way
we can enable P2P by default (which will make it easier for Flathub to
enable P2P support) without breaking builds of flatpak against versions
of ostree without the experimental API.
In the near future we should remove all the ifdefs so that the P2P
functionality becomes unconditional, but if we wait for flatpak to take
a dependency on ostree 2018.6 we can avoid breaking any builds.
(This is a redo of commit 34212ef24 that doesn't break builds of flatpak
against current ostree master, which doesn't yet have
https://github.com/ostreedev/ostree/pull/1596)
The pop was missing, meaning that calling flatpak_dir_find_latest_rev()
corrupted the thread default main context stack of the caller.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This reverts commit 34212ef249.
We need to wait until the p2p pr
(https://github.com/ostreedev/ostree/pull/1596) has landed, because otherwise
a git master build of ostree reports version 2018.6 and we assume it has
the p2p API.
ostree 2018.6 made the P2P API public that was previously experimental,
and added a "p2p" feature flag to replace "experimental". So this commit
updates the logic in flatpak's configure.ac so that we always enable P2P
support if ostree 2018.6 is available, and don't bother checking for a
feature flag or defining OSTREE_ENABLE_EXPERIMENTAL_API. This commit
also changes the behavior when flatpak is built against ostree <
2018.6. Specifically, P2P support is enabled if and only if we're
building against an ostree that has the relevant API, rather than
depending on the user to use `--enable-p2p` or `--disable-p2p`. This
way we can enable P2P by default (which will make it easier for Flathub
to enable P2P support) without breaking builds of flatpak
against versions of ostree without the experimental API.
In the near future we should remove all the ifdefs so that the P2P
functionality becomes unconditional, but if we wait for flatpak to take
a dependency on ostree 2018.6 we can avoid breaking any builds.
