I've just released a Cargo subcommand for building RPMs called 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
- `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:
...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:
Would it make sense to add the output from 'cargo-inspector --provides Cargo.toml' directly
to the .spec-file generated?
It would make my automatic build-dependency handling so much simpler!
How is the dependency handling done in the fedora buildfarm? Maybe I'm just reinventing my own
Anders Blomdell Email: anders.blomdell(a)control.lth.se
Department of Automatic Control
Lund University Phone: +46 46 222 4625
P.O. Box 118
SE-221 00 Lund, Sweden