Re: Help packaging a "C" library written in Rust

On Wed, Sep 07, 2022 at 02:40:51PM -0400, Stefan Hajnoczi wrote: > On Wed, Sep 07, 2022 at 02:30:23PM +0100, Richard W.M. Jones wrote: > > On Wed, Sep 07, 2022 at 08:50:24AM -0400, Stefan Hajnoczi wrote: > > > On Wed, Sep 07, 2022 at 10:05:55AM +0100, Richard W.M. Jones wrote: > > > > > > > >

Re: Help packaging a "C" library written in Rust

On Wednesday, 7 September 2022 11:35:54 CEST Richard W.M. Jones wrote: > On Wed, Sep 07, 2022 at 10:05:55AM +0100, Richard W.M. Jones wrote: > > > > > https://gitlab.com/libblkio/libblkio > > > > This is a library that offers a C API. It happens to be implemented > > in Rust, but it's not a

Re: Help packaging a "C" library written in Rust

As stated before in Fedora we definitely are against this way of packaging Go, Rust or pretty much anything else. This however doesn't apply to EPEL, CentOS or RHEL, where introducing and maintaining huge amount of dependencies because of one particular package doesn't make sense. Especially if

RE: Help packaging a "C" library written in Rust

Fabio Valentini writes: > On Wed, Sep 7, 2022 at 10:53 PM Stewart Smith via devel > wrote: >> >> For Amazon Linux, we take a different approach to Fedora (but similar to >> RHEL) for software written in Rust and Go, and instead bundle >> dependencies rather than have each module/crate in its own

Re: Help packaging a "C" library written in Rust

On Wed, Sep 7, 2022 at 10:53 PM Stewart Smith via devel wrote: > > For Amazon Linux, we take a different approach to Fedora (but similar to > RHEL) for software written in Rust and Go, and instead bundle > dependencies rather than have each module/crate in its own RPM. We do it > so we don't have

RE: Help packaging a "C" library written in Rust

"Richard W.M. Jones" writes: > On Wed, Sep 07, 2022 at 10:05:55AM +0100, Richard W.M. Jones wrote: >> >> https://gitlab.com/libblkio/libblkio >> >> This is a library that offers a C API. It happens to be implemented >> in Rust, but it's not a "Crate" or anything like that. >> >> I wrote a spec

Re: Help packaging a "C" library written in Rust

On Wed, Sep 07, 2022 at 08:50:24AM -0400, Stefan Hajnoczi wrote: > On Wed, Sep 07, 2022 at 10:05:55AM +0100, Richard W.M. Jones wrote: > > > > https://gitlab.com/libblkio/libblkio > > > > This is a library that offers a C API. It happens to be implemented > > in Rust, but it's not a "Crate" or

Re: Help packaging a "C" library written in Rust

On Wed, Sep 7, 2022, at 5:35 AM, Richard W.M. Jones wrote: > It was pointed out on the bug that librsvg2 is in a similar situation. > The answer there was to bundle ("vendor") all the Rust dependencies > into the tarball. The command "cargo vendor" does this. > > For librsvg2 that's 278MB of

Re: Help packaging a "C" library written in Rust

On Wed, Sep 7, 2022 at 11:36 AM Richard W.M. Jones wrote: > > On Wed, Sep 07, 2022 at 10:05:55AM +0100, Richard W.M. Jones wrote: > > > > https://gitlab.com/libblkio/libblkio > > > > This is a library that offers a C API. It happens to be implemented > > in Rust, but it's not a "Crate" or

Re: Help packaging a "C" library written in Rust

On Wed, Sep 07, 2022 at 10:05:55AM +0100, Richard W.M. Jones wrote: > > https://gitlab.com/libblkio/libblkio > > This is a library that offers a C API. It happens to be implemented > in Rust, but it's not a "Crate" or anything like that. > > I wrote a spec file for it assuming it's a C library

Help packaging a "C" library written in Rust

https://gitlab.com/libblkio/libblkio This is a library that offers a C API. It happens to be implemented in Rust, but it's not a "Crate" or anything like that. I wrote a spec file for it assuming it's a C library and it works fine when building locally: