RUST2RPM(1)

๐Ÿ“ฆ
version 28.3.0 ยท 4 versions
, in fedora 43, fedora 44

๐Ÿ’– NAME ๐Ÿ’–

rust2rpm โ€” okay so it literally generates RPM spec files for Rust crates. that's her whole thing, that's the job, and she's iconic at it ๐ŸŽ€


โœจ SYNOPSIS โœจ

rust2rpm [OPTION]... [pkgid]

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

rust2rpm is the tool that automatically generates RPM spec files for Rust crates. Her main character target is Fedora Linux, and support for other targets is provided on a best-effort basis โ€” like, she'll try, no promises though ๐Ÿ’…

Some of the way she behaves can be steered with command-line options, and some settings can be stored permanently in package-specific configuration files (c.f. rust2rpm.toml(5)) โ€” those get read if they're found in the current working directory. yes bestie, current working directory, iykyk ๐Ÿ‘‘

๐Ÿ’€ the big warning though: when you're packaging Rust crates that provide a library interface, you have to re-generate the spec file for every new version. every single one. this is required to keep the exact correspondence between crate "features" (including implicit features for optional dependencies) and RPM subpackages maintained. if that correspondence is not maintained, the resulting RPM package will either fail to build, have incomplete or wrong metadata (i.e. Provides or Requires), or fail to install due to unresolvable dependencies. not a vibe. not slay. regenerate the spec. ๐Ÿšจ

๐ŸŒธ POSITIONAL ARGUMENTS ๐ŸŒธ

  • pkgid โ€” this argument accepts a PKGID string similar to cargo, for referring to a crate name and version on crates.io, with both components being optional:
    • <name>
    • <name>@<version>
    • @<version>

If the <name> component is missing, the crate name is inferred from existing spec file contents and / or the name of the output directory. If the <version> component is missing, crates.io is queried for available versions of the specified crate, and the greatest stable version is used. ๐ŸŽฏ

Now, if the <version> component is a valid SemVer version, crates.io gets queried for this exact version of the specified crate โ€” and an error is raised if the specified version does not exist. alternatively, if the <version> component is a partial version or a SemVer version requirement, crates.io is queried for versions that match the given version requirement, and the greatest matching version is used. โœจ

Pre-release versions are never chosen automatically, and always need to be specified explicitly. periodt. ๐Ÿ™ˆ


๐Ÿ’… OPTIONS ๐Ÿ’…

  • -C [PATH], --config-file=[PATH] โ€” load rust2rpm configuration from the specified path instead of the default path (./rust2rpm.toml). raises an error if this file does not exist. no file, no vibes. ๐Ÿ˜ญ
  • -o [PATH], --output-directory=[PATH] โ€” specify the directory to which any output files should be written. if this directory does not exist yet, it will be created. she's proactive like that ๐Ÿซถ
  • -t [TARGET], --target=[TARGET] โ€” write a spec file tailored to the specified distribution target. the default value is determined by the contents of os-release(5). valid values are fedora, mageia, opensuse, and plain. pick your fighter ๐Ÿ’–
  • -V [MODE], --vendor=[MODE] โ€” this option enables generating a spec file that builds against dependencies from a vendor tarball instead of packaged Rust crates. the default mode is off, i.e. generate a spec file for building without a vendor tarball. in auto mode, a vendor tarball is automatically generated with default settings, but both automatic and manually written patches (the --patch option) are taken into account. using manual mode skips the automatic generation of the vendor tarball, and is intended to be used when manually creating a vendor tarball in cases where auto mode is not flexible enough. lowkey the whole spectrum of control ๐Ÿ’…
  • -P [VERSION], --prev-version=[VERSION] โ€” this argument allows overriding the detected "previous" / "old" version when generating a diff report between an "old" and the "new" crate version, instead of trying to parse an existing spec file to determine the old version. manual override, main character energy ๐Ÿ’œ

๐Ÿ”ฅ FLAGS ๐Ÿ”ฅ

  • -a, --rpmautospec, --no-rpmautospec โ€” explicitly enable or disable use of rpmautospec. the default setting is enabled on Fedora but disabled for other targets โ€” the Target Support section has more information about the differences between supported targets. โœจ
  • --compat โ€” generate a spec file for an alternative version of a crate, applying a version suffix automatically derived from the crate version to the package name. this is the recommended way to create "compat" packages, since it will generate packages that follow the guidelines for package names when packaging multiple versions of the same project. for versions past 1.0, the suffix is the <major> version; for versions between 0.1 and 1.0, the suffix is <0.minor>; and for versions before 0.1 the suffix is <0.0.patch> โ€” all according to the SemVer API stability guarantees as implemented in cargo. math but make it fashion ๐Ÿงฎ๐Ÿ’…
  • --no-existence-check โ€” do not check whether the package already exists in Fedora dist-git. the default setting is enabled on Fedora but disabled for other targets. this first checks whether the dist-git repository exists, and if it exists, whether there is a spec file in the current rawhide branch (so retired packages also count as "non-existent"). ๐Ÿ‘ป
  • -N, --no-reports โ€” skip generating reports with checks that are potentially slow to run. currently, that's the ingredients based "diff" between the previous and current version of a crate, and the "report" for potential differences between the published crate tarball and the linked upstream repository. she said no slow check energy today ๐Ÿƒโ™€๏ธ๐Ÿ’จ
  • -o, --offline โ€” avoid accessing network resources (crates.io, src.fedoraproject.org). this mode requires specifying crate versions fully on the command line, since matching versions cannot be queried from crates.io, and the corresponding .crate file needs to already have been downloaded into the cache. airplane mode but for packaging โœˆ๏ธ
  • -p, --patch โ€” open Cargo.toml in the default editor to apply changes and generate a patch file before loading project metadata from this file. this is the only supported way to patch Cargo.toml, since many changes to this file affect the content of the generated spec file. one way. the way. ๐ŸŽ€
  • --no-patch-foreign โ€” do not automatically strip non-applicable target-specific dependencies from Cargo.toml. this option can be used if the implementation for stripping these dependencies results in broken metadata. pretty please file bug reports for cases like this (including the name and version of the affected crate) ๐Ÿ™๐Ÿซถ
  • -r, --reuse-patch โ€” this flag can be used to attempt re-applying an existing patch file instead of opening an editor, for example for non-interactive use or when re-running rust2rpm for a reason other than changing the patch for Cargo.toml. this flag works in conjunction with the --patch flag: if only this flag is present and the existing patch fails to apply, rust2rpm exits with an error. if both flags are present, rust2rpm falls back to opening Cargo.toml in an editor so the patch can be manually rebased. teamwork makes the dream work ๐Ÿค
  • -s, --store-crate โ€” store the .crate file downloaded from crates.io in the current directory (not applicable if the crate argument points to a local file or directory). if this option is not passed, crates are only stored in rust2rpm's cache directory ($HOME/.cache/rust2rpm/). ๐Ÿ’พ
  • -v, --validate-only โ€” only load configuration files, validate them, and exit. crate metadata is not loaded in this mode, so not all configuration options can be fully validated. quick vibe check then she's out ๐Ÿงš

๐Ÿšง Deprecated flags ๐Ÿšง

These flags will be removed in the next major version of rust2rpm. use them while you can bestie, they're on their farewell tour ๐Ÿ˜ญ

  • --no-auto-changelog-entry โ€” do not include a generic %changelog entry in the generated spec file. by default, this is enabled on all targets. passing this option will result in more easily diffable spec files. ๐Ÿ“

๐ŸŒˆ TARGET SUPPORT ๐ŸŒˆ

While the primary supported target is Fedora Linux, rust2rpm also has best-effort support for generating spec files that should work on other distributions (EPEL 8, Mageia, OpenSUSE, and other generic RPM-based Linux with the plain target). she's poly-target and proud ๐Ÿ’–

๐Ÿ‘‘ Fedora

The fedora target enables all features that are supported by rust2rpm, but which often require the latest versions of rust-packaging (i.e. cargo-rpm-macros) and / or cargo2rpm.

  • set Release and %changelog for use with rpmautospec
  • rely on RPM generators for setting BuildRequires, Requires, and Provides
  • do not set Group tag

๐Ÿ“ Mageia

  • generate a manual changelog entry in the format expected on Mageia
  • rely on RPM generators for setting BuildRequires, Requires, and Provides
  • set Group tag to "Development/Rust"

๐ŸฆŽ OpenSUSE

  • hard-code BuildRequires in the generated spec file
  • rely on RPM generators for setting package Requires and Provides
  • include spec file header as expected for OpenSUSE packages
  • generate a manual changelog entry in the format expected on OpenSUSE
  • set Group tag to "Development/Libraries/Rust"

๐ŸŒฑ Plain

The plain target has more limited requirements, and should produce working packages for environments without RPM generators for Rust crates:

  • hard-code BuildRequires, Requires, and Provides in the generated spec file
  • generate a manual changelog entry in the generic format supported by RPM

๐Ÿ  HOMEPAGE ๐Ÿ 

https://codeberg.org/rust2rpm/rust2rpm

go say hi, she lives there ๐Ÿฅฐ


๐Ÿ‘€ SEE ALSO ๐Ÿ‘€

rust2rpm.toml(5), rust2rpm.conf(5)

read the friends too, they matter ๐Ÿซถ


okay that's the whole thing bestie, no cap, every last detail accounted for ๐Ÿ’ฏ this was rust2rpm, dated 2026-10-13, and yes she's still that girl. mwah ๐Ÿ’‹๐Ÿ’–โœจ

๐Ÿ“ฆ where this page comes from