Re: libostree v2017.2

[Leon Woestenberg <leon sidebranch com>]

Hi Colin,

On Tue, Feb 14, 2017 at 7:42 PM, Colin Walters <walters verbum org> wrote:

https://github.com/ostreedev/ostree/releases/tag/v2017.2

Good Stuff!

In response to your "please let us know":

 

`--enable-rust`: This is an experiment in following a similar plan to what Firefox is doing with
Rust.  When this build time option is enabled, a very small bit of libostree (the
rsync-style rollsum code) is in Rust, and linked statically into the rest of the
library.  There are no plans right now to make this a hard requirement in the
near future.  Please let us know if a dependency on Rust would be
a blocker for your usage of libostree.

There are a few projects experimenting with OSTree based atomic updates on operator-less remotely-managed, embedded devices, where the hard-inclusion of a Rust dependency would bring a few hurdles. (I am not saying show-stopper.) I know of Automotive Grade Linux (Yocto, Tizen based) and some other OpenEmbedded / Yocto projects. I am personally also trying to use it in real-world embedded projects.

These project cross-compile (lib)ostree up-front on a development host, and from what I understand, the Rust dependency is mostly host-side, although I am unfamiliar enough with Rust's host-side/build-time vs. run-time/target dependencies.

As long as the core features for such systems are C-only and Rust-add-ons are optional, there is no blocker. Once Rust becomes a hard-dependency there are hurdles to take.

There are no plans right now to make this a hard requirement in the near future.

What is near future? In projects like Yocto/OpenEmbedded, we have seen full support for new languages (and all their cross-compilation issues) can take one to a few years to completion, sometimes because upstream doesn't care much about it. (For example, Swift, Go, ...)

Regards,

Leon.