pruning tries to traverse into parent repos

[cgwalters]

Trying to prune my rpm-ostree pkg cache repo doesn't work because we try to delete objects that came from the parent (but fail because we try to unlinkat() in the pkgcache repo).

[cgwalters]

There are a few things related here. One is https://bugzilla.gnome.org/show_bug.cgi?id=764735
Another that I noticed is...we're not actually today deduping objects with parents! In write_object() we do:

  if (!_ostree_repo_has_loose_object (self, actual_checksum, objtype, &have_obj,
                                      cancellable, error))
    goto out;

Which doesn't, and AFAICS has never traversed into parent repos. Doing some archaeology, I found:
5947b5b
But I don't think I ended up making use of that.

Hmm, though the pull code does consult parent repos for objects. So flatpak's use of parent repos here makes sense. But rpm-ostree's importer is using the libarchive->commit path, which doesn't.

[cgwalters]

Some design discussion here:coreos/rpm-ostree#107 (comment)

However, rereading that, I still don't quite understand why we ended up adding the parent= config; was it basically just in hope that we'd dedup? But if we did start doing that it'd become dangerous with pruning in the current model.

[jlebon]

Just to summarize what we discussed on IRC about this. There are two distinct issues here. The pkgcache repo was made separate of the base repo so that it wouldn't be affected by ostree's pruning. Its parent= config is right now AFAICT only actually necessary so that we can clone the version from the base commit, which should be trivial to unlink (my vague memory of this is that it was required for something else as well in the initial implementations of pkg-layering).

Once #262 is fixed, we can store it in the same repo and as a plus gain proper deduping.

[cgwalters]

Addressed by #471