RUST2RPM.CONF(5)

📦
version 28.3.0 · 4 versions
, in fedora 43, fedora 44

🎀 rust2rpm.conf — the rust2rpm config file, but make it (5) 🎀

okay bestie, welcome to the manual for rust2rpm.conf, page 5 of the manual set. it's the package-specific config file for rust2rpm, and yes — it's deprecated, we'll get to that, don't panic 💅

✨ NAME ✨

rust2rpm.conf — the package-specific configuration file for rust2rpm (and it is, lowkey, deprecated) 🫶

🌸 DESCRIPTION 🌸

so here's the tea 🍵 — some aspects of rust2rpm(1) can be configured by setting package-specific preferences in a rust2rpm.conf file. if a file with this exact name is chillin' in the current working directory when you run rust2rpm, it gets loaded automatically. no flag, no nothing, it just finds you ✨

🚨 okay so this is the big one: this configuration file format is deprecated and has been superseded by rust2rpm.toml(5), which supports a superset of the settings that are available in rust2rpm.conf. rest in peace queen 💀

the file format for rust2rpm.conf is based on the INI format as implemented in the configparser module from the Python standard library. and the iconic part? settings in the [DEFAULT] section can be overridden by target-specific settings — i.e. settings under a [fedora], [mageia], or [plain] section. this layered-settings support is rarely used and has not been implemented in rust2rpm.toml(5), so don't come looking for it there 🙈

💖 OPTIONS 💖

  • summary — this setting overrides the value of the RPM Summary tag. use it when the summary generated from crate metadata based on heuristics is just not good enough. be honest, the heuristic isn't always slaying ✨
  • supported-arches — use this to say that the crate only supports a limited set of architectures (aka not every CPU architecture the distro supports). it accepts a line-separated / indented list of target architectures. if this setting is present, the cargo build and cargo test steps in the generated spec file get wrapped with %ifarch conditionals. iconic behavior, conditional queen 👑
  • all-features — when enabled, this makes the -a / --all-features flag get passed to all cargo calls. perfect for crates where running tests needs optional features enabled, or for applications where enabling all features is just the vibe. it accepts a "bool-like" value. careful though: setting all-features to true-ish requires the enabled-features setting to be unspecified or to be empty 🫶
  • enabled-features — more fine-grained control for passing feature flags to cargo calls. accepts a line-separated / indented list of names of enabled features. and same energy in reverse: setting enabled-features to a non-empty list requires the all-features setting to be unspecified or to be false-ish. they cannot both be the main character 😭
  • unwanted-features — this one stops subpackages for crate features and implicit features for optional dependencies from being generated in the spec file. super useful for crates that have unused non-default features which pull in extra dependencies (we hate a freeloader 💅). it accepts a line-separated / indented list of names of "unwanted" crate features.
⚠️ NOTE: you gotta be careful to only "hide" features / optional dependencies that are not dependencies of other "non-hidden" features. otherwise the subpackages for the dependent features will have unsatisfiable dependencies and everything falls apart. all features marked as "unwanted" by this setting must be "unreachable" via feature dependencies from any feature subpackages that are still present in the generated spec file. and sometimes — sadly — the only clean way to handle removal of unused non-default features is to patch Cargo.toml instead. iykyk 🩹
  • buildrequires — extra BuildRequires for the package go here. it accepts a line-separated / indented list of BuildRequires in the syntax supported by RPM. these get either added in the %generare_buildrequires scriptlet for targets where that's enabled, or added as plain BuildRequires for targets without dynamically generated BuildRequires. (yes, we're keeping that spelling exactly as it is, no cap 🫡)
  • testrequires — this one lets you add extra BuildRequires that are only needed when running a project's test suite (i.e. cargo test). works exactly the same as the setting for additional BuildRequires, except all the entries get wrapped in an %if %{with check} conditional. conditional and cute 🌸
  • lib.requires — with this, you can add extra dependencies (Requires) for the main -devel subpackage of a "library crate". for example, so many -sys bindings need the development headers for the wrapped C library to be present both when building the package for the crate itself and when building a package that depends on this crate. in those cases the same dependency often needs to be added as both buildrequires and lib.requires. accepts a list of line-separated / indented RPM dependencies ✨
  • lib+foo.requires — works just like lib.requires, except it adds extra dependencies to subpackages for crate features. you can specify it multiple times, and dependencies listed for "foo" get added to the -devel subpackage for feature "foo" instead. only valid feature names are accepted — specifying a non-existent feature will cause a validation failure, so no making up features bestie 😭
  • bin.requires — for crates that include application binaries / executables, this adds extra dependencies for the subpackage that contains those executables. accepted values are line-separated / indented strings that are valid RPM dependencies 🧚

🦋 MIGRATING TO RUST2RPM.TOML 🦋

running rust2rpm for a package that still uses a rust2rpm.conf configuration file? it gets automatically converted and rewritten into a rust2rpm.toml file that contains equivalent settings. glow up, no effort required 💅

the rust2rpm.toml(5) configuration file format supports a superset of the settings available in rust2rpm.conf, except that "layered" configuration is not supported. tragic, but we move 🌈

here's the whole mapping, every single one, no skipping:

  1. summary: moved to the "summary" setting in the [package] table, accepts a TOML string
  2. supported-arches: moved to the "supported-arches" setting in the [package] table, accepts a TOML array of strings
  3. all-features: moved to the "enable-all" setting in the [features] table, accepts a TOML boolean
  4. enabled-features: moved to the "enable" setting in the [features] table, accepts a TOML array of strings
  5. unwanted-features: moved to the "hide" setting in the [features] table, accepts a TOML array of strings
  6. buildrequires: moved to the "build" setting in the [requires] table, accepts a TOML array of strings
  7. testrequires: moved to the "test" setting in the [requires] table, accepts a TOML array of strings
  8. lib.requires: moved to the "lib" setting in the [requires] table, accepts a TOML array of strings
  9. bin.requires: moved to the "bin" setting in the [requires] table, accepts a TOML array of strings
  10. lib+foo.requires: moved to the "features" table in the [requires] table, accepts a table with keys that must match feature names, and TOML arrays of strings as values

🌟 EXAMPLES 🌟

🎀 Bindings for system libraries 🎀

one typical use case for a rust2rpm.conf file is packages for crates that contain bindings for system libraries — especially when crate features are used to control which APIs of the library get made available. very main character energy of them ✨

example file from the package for gtk4-sys version 0.7.3 on Fedora 38, where version 4.10 of gtk4 is available:

[DEFAULT]
unwanted-features =
  v4_12
  v4_14
buildrequires =
  pkgconfig(gtk4) >= 4.0.0
lib.requires =
  pkgconfig(gtk4) >= 4.0.0
lib+v4_2.requires =
  pkgconfig(gtk4) >= 4.2
lib+v4_4.requires =
  pkgconfig(gtk4) >= 4.4
lib+v4_6.requires =
  pkgconfig(gtk4) >= 4.6
lib+v4_8.requires =
  pkgconfig(gtk4) >= 4.7
lib+v4_10.requires =
  pkgconfig(gtk4) >= 4.10

🍓 External dependencies of the Rust standard library 🍓

the Rust standard library depends on some crates that are also published separately, and a "hack" is used when building these crates as part of std. the crate features and optional dependencies used for this purpose are useless in other situations — literally zero use anywhere else 💀

example file from the package for libc version 0.2.148:

[DEFAULT]
unwanted-features =
  rustc-dep-of-std
  rustc-std-workspace-core
buildrequires =
  glibc-devel
lib.requires =
  glibc-devel

👑 HOMEPAGE 👑

https://codeberg.org/rust2rpm/rust2rpm

💜 SEE ALSO 💜

rust2rpm(1), rust2rpm.toml(5)

and that's the whole page bestie 🫶 this was the rust2rpm.conf(5) manual for rust2rpm, dated 2026-10-13. go migrate to rust2rpm.toml fr fr, your future self will thank you 💖✨🎀🦋

📦 where this page comes from