Hello everyone,
I've just released a Cargo subcommand for building RPMs called cargo-rpm:
https://crates.io/crates/cargo-rpm
I've tried to avoid heavy handed abstractions and have implemented it in such a way that it does as little as possible, which is effectively two things:
- `cargo rpm init`: a one-time command which automatically generates an RPM spec from Cargo.toml metadata, intended to be checked-in
- `cargo rpm build`: creates a target/release/rpmbuild directory, copies the spec into the SOURCES directory (after templating in a version number), creates a tarball of release artifacts (and other optional files) in the SOURCES directory, then spawns "rpmbuild" as a subprocess, having it place the resulting RPM in target/release/rpmbuild/RPMs/<arch>
Since releasing this I've found out this sort of thing is being worked on in the Rust CLI WG:
https://github.com/rust-lang-nursery/cli-wg/issues/8
...and have also discovered rust2rpm. I think rust2rpm might have slightly different goals though? Where cargo-rpm is designed to instrument a project to build RPMs using the cargo workflow, it seems rust2rpm is more targeted at retroactively building RPMs from crate releases.
My main intended usage of cargo-rpm is packaging releases of internal CLI tools for internal repositories, however if there's interest in using it for packaging releases of Rust projects for official repos, I'm happy to accommodate changes necessary to make that happen.
If nothing else I'd love some feedback on the spec files I'm generating. Here's the template:
https://github.com/iqlusion-io/crates/blob/master/cargo-rpm/templates/spec.h...
Whoops, though I included it in the title, I forgot to mention: I also took a shot at writing some Rust bindings to librpm/rpmlib, after first generating bindings using bindgen:
https://github.com/iqlusion-io/crates/tree/master/rpmlib
I've gotten some great feedback from upstream RPM developers, particularly around the mistakes of previous bindings:
https://github.com/rpm-software-management/rpm/issues/429
I'm still not super happy with the code on master, but I think I have a path forward that should balance performance and memory safety concerns. I also deliberately plan on exposing as few features as possible in the public API, at least initially, as it seems a common problem with previous bindings was exposing all of rpmlib's functionality including things characterized as misfeatures by RPM's developers.
I should also note I'd be happy to upstream either of these projects to the right home (and already have some interest on upstreaming the librpm/rpmlib code to RPM itself), and am happy to relicense it or do whatever is needed.
-
Tony Arcieri