lib/repo-commit: Relax min-free-space check in prepare_transaction()

We want a case where we can disable the min-free-space check. Initially,
it felt like to add a OSTREE_REPO_PULL_FLAGS_DISABLE_FREE_SPACE_CHECK but
the problem is prepare_transaction() does not have a OstreeRepoPullFlags
parameter which we can parse right here. On top of it, prepare_transaction()
enforces min-free-space check and won't let the transaction proceed if
the check failed.

This is pretty bad in conjunction with "inherit-transaction" as what
Flatpak uses. There is no way to disable this check unless we remove
it altogether from prepare_transaction.

This issue came out to light when flatpak wasn't able to write metadata
after fetching from remote:

[uajain@localhost ~]$ flatpak remote-info flathub org.kde.Platform//5.9
error: min-free-space-size 500MB would be exceeded

Metadata objects helps in housekeeping and restricting them means
restricting crucial UX (like search, new updates) functionalities
in clients like gnome-software. The error banners originated from
these issues are also abrupt and not much helpful to the user. This
is the specific instance of the issue this patches tries to address.

See https://github.com/flatpak/flatpak/issues/2139 for discussion.

Closes: #1779
Approved by: mwleeds

1 files changed, 12 insertions, 3 deletions

diff --git a/src/libostree/ostree-repo-commit.c b/src/libostree/ostree-repo-commit.c
index 6cd3fcf4..533cf03a 100644
--- a/src/libostree/ostree-repo-commit.c
+++ b/src/libostree/ostree-repo-commit.c
@@ -1624,9 +1624,18 @@ ostree_repo_prepare_transaction (OstreeRepo     *self,
     self->txn.max_blocks = bfree - self->reserved_blocks;
   else
     {
-      self->cleanup_stagedir = TRUE;
-      g_mutex_unlock (&self->txn_lock);
-      return throw_min_free_space_error (self, 0, error);
+      self->txn.max_blocks = 0;
+      /* Don't throw_min_free_space_error here; reason being that
+       * this transaction could be just committing metadata objects
+       * which are relatively small in size and we do not really
+       * want to block them via min-free-space-* value. Metadata
+       * objects helps in housekeeping and hence should be kept
+       * out of the strict min-free-space values.
+       *
+       * The main drivers for writing content objects will always honor
+       * the min-free-space value and throw_min_free_space_error in
+       * case of overstepping the number of reserved blocks.
+       */
     }
   g_mutex_unlock (&self->txn_lock);