This splits the builder completion step into separate actions for
creating/loading a sysroot.
It also introduces a roundtrip test over a freshly-created empty
sysroot.
This adds a `SysrootBuilder` in order to allow consumers to load
a configured `Sysroot` in an ergonomic way. It tries to prevent
logic bugs coming from handling half-initialized entities.
The `resolve_rev` C method should really have been
`resolve_rev_optional` from the start - it is more obviously wrong
in Rust because the input parameter `allows_noent` controls
whether the returned `Option` can ever be `None`.
I debated adding this to the C bindings, and may still do so,
but eh it's faster to write + ship in Rust, and the future of ostree is
Rust anyways.
This gives auto-cancelling semantics on `Drop`, plus a nicer
`.commit()` method on the transaction.
Matches the currently private `_OstreeRepoAutoTransaction` in the C
library.
In general only `-sys` crates should depend on other `-sys`
crates. IOW for us, `ostree-sys` depends on `glib-sys`.
By using the re-export, we avoid needing to keep a version lock
between `glib` and `glib-sys` in our main crate. And similar
is true of our higher level reverse dependencies (e.g. `ostree-rs-ext`).
Also weaken our dependency to `0.14` as that's clearer.
This way it's more convenient for downstream crates like ostree-rs-ext
to convert loaded variants.
TODO: Can we add a feature for the `gvariant` crate and expose via
that too?
An intimidating spam of compiler errors at the start, but the
biggest was handling the new convention of `ostree_sys::` => `ffi::`.
This will require a semver bump of course.
Ultimately a repo is just a file descriptor wrapper with some
cached data, etc. We can send it between threads, much like how
`gio::File` is `Send`.
Motivated by trying to write to a repo from a separate thread
in https://github.com/cgwalters/ostree-container
I don't think the SignDummy and SignEd25519 types even need to be
visible. The explicit dummy_* and ed25519_* don't need to be visible
either, I suspect.