Re: Help packaging a "C" library written in Rust
On Wed, Sep 7, 2022 at 11:36 AM Richard W.M. Jones <rjones(a)redhat.com> 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 anything like that.
>
> I wrote a spec file for it assuming it's a C library and it works fine
> when building locally:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2124697
>
> However it turns out that it downloads stuff during the build and
> therefore won't build in Koji. Apart from reading the Rust packaging
> guidelines which don't seem applicable here (as this is not a Rust
> Crate), that's as far as I've got on this one.
>
> Has anyone packaged anything like this for Fedora?
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 dependencies (10 times larger than the
sources of librsvg2 itself) in 265 separate Rust libraries. For
libblkio it's 123MB of dependencies in a mere 21 libraries.
Also there's no Provides: bundled(...) in the librsvg2 package.
librsvg2 was one of the first C libraries that built Rust stuff, and
as such it's not a good example for how to do things today.
FYI, @kalev is also working on un-bundling the Rust dependencies from
it, and is currently submitting missing dependencies for review.
Better examples would probably be:
- rav1e: AV1 encoder library (uses cargo-c, which provides convenience
functionality for handling .so* symlinks, pkg-config files, header
files, etc.)
- libkrun: container / KVM stuff (seems to be a similar case as
libblkio, they also set soname/version manually, etc.)
- rpm-sequoia: new/next OpenPGP backend for RPM (still under review @
RHBZ#2124697, uses helper functionality from cdylib-link-lines for
setting soname/version etc.)
The most convenient solution is using cargo-c as it handles all the
"C-library"-isms (.so* symlinks, pkg-config files, header files, etc.)
for you automatically (c.f. the rav1e spec file), but that would
require buy-in from upstream, as it requires a small amount of
manually maintained configuration. If that's not possible, then the
approach used by libkrun (doing things manually) seems to be pretty
good.
Fabio