On Wed, Sep 25, 2019 at 01:52:08PM -0400, Randy MacLeod wrote:
> On 9/24/19 6:18 AM, Adrian Bunk wrote:
> > On Mon, Sep 23, 2019 at 10:45:05PM -0400, Randy MacLeod wrote:
>...
> > There are also related topics like how to provide security support
> > for vendored libraries - this is the main reason why vendored libraries
> > shipped by upstream are rarely used by distributions in the C ecosystem.
> 
> Yes, we need to have a plan for security and bug fixes.
> Of course Rust is largely impervious to such 20th century problems.
> (mostly joking!)

vendor/ in the librsvg 2.46.0 tarball are 145 crates (157 MB).
vendor/ in the rust 1.37.0 tarball are 350 crates (308 MB).

>...
> > > 5. make rust-hello-world install for qemuriscv64
> > >     https://github.com/meta-rust/meta-rust/issues/252
> > 
> > LLVM in meta-rust is too old for RISC-V.
> 
> Right.
> I'm away Thursday to Sunday but
> I'll work on a fix for that when I'm back.

It needs LLVM 9, plus RISC-V support that is not yet in upstream Rust.

Not sure whether the latter requires more than just a target definition,
but this will likely just work if you wait a few months.

>...
> > Using an own LLVM recipe might makes sense for an external layer, but in
> > oe-core the llvm recipe that is already there should be used instead of
> > another copy of LLVM.
> 
> I agree that the goal should be to have a single llvm package but
> it's an upstream Rust decision.

For upstream it is better to have an own copy of LLVM,
but for a distribution it can be beneficial to avoid having
mesa/rust/clang/... each shipping and building own copies
of LLVM.

> I did look at the differences between the 'forks' and they are significant.

In Debian Rust uses the same LLVM as everything else.

>...
> > 2.44 built for me a few months ago with meta-rust.
> 
> Can you share the recipe so I can use it and update it to 2.46?

Attached, the only other noteworthy change was that upstream
removed rsvg-view.

>...
> > > What have I missed?
> > > ...
> > 
> > 9. Ensure that there are no non-optional dependencies on the target
> >     librsvg since users will build for targets not supported by Rust.
> >     The one in webkitgtk seems to be optional or obsolete.
>...
> To deal with such targets, we'd keep the old version of librsvg
> around for a while longer. That could cascade into several
> packages with duplicate versions in oe-core so it may be best handled
> with a separate layer.

This sounds unsustainable, similar to meta-gplv2.

Right now the only dependencies on librsvg in oe-core are webkitgtk 
(unused, I'll submit a patch removing it after the Yocto 3.0 branching) 
and an optional dependency in gstreamer1.0-plugins-bad, so likely no 
problem at the moment.

But with software like bzip2 also moving to Rust this is something
that that might need continued attention.

There are people submitting patches for e.g. big endian arm to OE,
and there is value in ensuring that OE stays usable for such usecases.

> > 10. Review the whole contents of the layer.
> >      There are several things where I hope there are better solutions,
> >      and I expect that what will land in oe-core will look quite
> >      different from the current meta-rust.
> >      See item 5 above for an example.
> 
> Yes, if we require separate bitbake recipes for each package
> that would require significant changes to the current layer.

This is not about specific issues.

There are plenty of other cases like for example rust.inc being
the wrong place for OE target -> LLVM target mappings in oe-core, 
if they are needed at all.

> Thanks,
> 
> ../Randy

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed