Re: libostree v2017.2

[Anton Gerasimov <anton advancedtelematic com>]

Hi,

agree with Leon. Right now we ARE using rust on embedded devices, because our update client is written in Rust. However we are now working on porting our client to C++, since depending on Rust creates unexpected portability issues here and there and also increases image creation time in OpenEmbedded by about 45-60 minutes. So I would prefer not being dependent on Rust, although by the time the porting process is finished, Rust support in OE may improve as well.

Thanks,
Anton

On 02/21/2017 02:45 PM, Leon Woestenberg wrote:

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.

_______________________________________________
ostree-list mailing list
ostree-list gnome org
https://mail.gnome.org/mailman/listinfo/ostree-list

-- 
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg