Re: ostree oxidation: internal components written in Rust

[Colin Walters <walters verbum org>]

On Tue, Dec 18, 2018, at 1:53 PM, Anton Gerasimov via ostree-list wrote:
> Hi,
>
>
> > We are using ostree in embedded Linux, built with minimal dependencies (in
> > terms of packages and cross-build tools) building it from Yocto.
> >
> > Our interest is in having the ostree core available in C.
>
> Same here. It is not impossible to build Rust code in Yocto, but it
> increases maintenance burden and build time significantly.

Hmm; is there any discussion of this elsewhere - have any handy
links to e.g. mailing list archives?  Can you elaborate a bit
on the maintenance overhead?  Is it around dealing with crates.io sync?
On that topic I found
https://lists.yoctoproject.org/pipermail/yocto/2017-March/035028.html

For build time, is that building rustc for the host?  (including LLVM?) Or just general Rust
compilation times even on target?

Bigger picture...I really don't want to lose OSTree's existing user base.
It's really great (and humbling) to see what you all are doing with it!
That conservatism is what has held me back from pushing the Rust
requirement more.  (Also the fact that it's been very useful for us to
gain experience with it in the rpm-ostree context)

I think last time this came up on the list we floated the idea of having a Rust requirement
only for *build time* things, such as the static delta building code (which
would hugely benefit from oxidation).   It's been almost 2 years since
then, and Rust has rather notably increased in traction.
(And Felix posted new bindings!)

We could try to actually move some server-side stuff out into a separate
repository (which...I guess really gets straight into https://github.com/alexlarsson/repo-manager )

But...there's a whole lot of stuff I'd love to do in the libostree core that
become a lot nicer with Rust.  For example I'd like to do more parallelization
(particularly of commits and checkouts).  Another good example is
tackling the monster that is ostree-repo-pull.c.  

So: we may need to try to negotiate some sort of timeframe here.