Re: libostree v2017.2



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]