Re: API question & Rust API bindings

[Felix Krull <f_krull gmx de>]

On Mon, 22 Oct 2018 at 17:03 Colin Walters <walters verbum org> wrote:

The type of an object is carried externally; stored in the repository it's
the filename suffix.  Similarly, the checksum is stored externally, and
so is the size (just encoded in the Unix stat buffer). This means that any
protocol serializing an object also needs to carry at least that 3-tuple of
(objtype, checksum, size).

One thing I'd like to enable better is augmenting tar slightly and supporting
that as a serialization format.  If the server doesn't trust the client (i.e. it
will be recomputing checksums), I don't think there's a huge advantage to
sending native ostree object formats rather than just having the server re-synthesize
them.  One just needs to send the commit object out-of-band; the dirtree/dirmeta
and content objects get re-synthesized.

Well, my objective was mostly to avoid having to figure out the exact contents of the objects. :D So I was trying to get by with just taking objects out of one repo and putting them in another without looking at the structure. It seems I can still do that, I just need to make a distinction between content and metadata on the deserialization end.

 

> And, semi-unrelated to that, I built some Rust bindings for libostree,
> automatically generated from the gobject-introspection metadata. They're
> pretty incomplete because I only needed Repo so that's all I added for now.
> The code lives here: https://gitlab.com/fkrull/rust-libostree There's also
> a crates.io release: https://crates.io/crates/libostree

This is *awesome*!  I looked over your code some, and it looks
good to me overall, though I have to admit to not (yet) being
very familiar with the gtk-rs binding infrastructure[1].

Well, unsurprisingly most of the code is auto-generated. gir (the gtk-rs tool) doesn't support hash tables and arrays very well (or at all) yet, which means quite a few methods at least in the OstreeRepo API need to be hand-wrapped.

 

I'm also interested in what you're using libostree for, if you care to share?
(But you don't have to of course!)

My original goal was to build OSTree-based systems from Debian, i.e. like rpm-ostree compose but using Debian packages and repositories. My sub-goal with that was that I wanted an OSTree-based system to run on my Raspberry Pis. (Which I could probably do with Fedora as well, to be fair.)

But I got a bit side-tracked with tooling. Another thing I ended up making is "deploy-ostree" (https://gitlab.com/fkrull/deploy-ostree), which is really just a tool to automate setting up a remote, pulling and deploying an OSTree commit, and then performing some basic provisioning to make it bootable. The original idea was for automated tests, but it has been immensely useful for manual tests for me as well.

I should probably stop getting distracted and go work on the Debian aspect again. But when/if I get around to rewriting my current builder shell script into something more fancy, I'll probably use Rust so this'll still come in useful then.