1RUST2RPM.CONF(5) rust2rpm RUST2RPM.CONF(5)
2
6 rust2rpm.conf - package-specific configuration file for *rust2rpm*
7 (deprecated)
8
10 Some aspects of rust2rpm(1) can be configured by setting
11 package-specific preferences in a rust2rpm.conf file. If a file with
12 this name is present in the current working directory when running
13 rust2rpm, it is loaded automatically.
14 This configuration file format is deprecated and has been superseded by
16 rust2rpm.toml(5), which supports a superset of the settings that are
17 available in rust2rpm.conf.
18 The file format for rust2rpm.conf is based on the INI format as
20 implemented in the configparser module from the Python standard
21 library. Notably, settings in the [DEFAULT] section can be overridden
22 by target-specific settings (i.e. with settings under a [fedora],
23 [mageia], or [plain] section). This rarely used support for layered
24 settings has not been implemented in rust2rpm.toml(5).
25
27 summary
28 This setting is used to override the value of the RPM "Summary" tag
29 and can be used if the summary generated from crate metadata based
30 on heuristics is not good enough.
31 supported-arches
33 This setting can be used to specify that the crate only has support
34 for limited architectures (i.e. not all CPU architectures that are
35 supported by the distribution). This setting accepts a
36 line-separated / indented list of target architectures. If this
37 setting is present, the "cargo build" and "cargo test" steps in the
38 generated spec file are wrapped with "%ifarch" conditionals.
39 all-features
41 When enabled, this setting causes the "-a" / "--all-features" flag
42 to be passed to all cargo calls. This can be used for crates where
43 running tests requires optional features to be enabled, or for
44 applications where enabling all features is desirable. This setting
45 accepts a "bool-like" value. Setting all-features to true-ish
46 requires the enabled-features setting to be unspecified or to be
47 empty.
48 enabled-features
50 This setting provides more fine-grained control for passing feature
51 flags to cargo calls. It accepts a line-separated / indented list
52 of names of enabled features. Setting enabled-features to a
53 non-empty list requires the all-features setting to be unspecified
54 or to be false-ish.
55 unwanted-features
57 This setting can be used to prevent subpackages for crate features
58 and implicit features for optional dependencies from being
59 generated in the spec file. For example, this can be useful for
60 crates that have unused non-default features which pull in
61 additional dependencies. It accepts a line-separated / indented
62 list of names of "unwanted" crate features.
63 NOTE: Care needs to be taken to only "hide" features / optional
64 dependencies that are not dependencies of other "non-hidden"
65 features, otherwise the subpackages for the dependent features will
66 have unsatisfiable dependencies. All features that are marked as
67 "unwanted" by this setting must be "unreachable" via feature
68 dependencies from any feature subpackages that are still present in
69 the generated spec file. In some circumstances, the only way to
70 cleanly handle removal of unused non-default features is to patch
71 Cargo.toml instead.
72 buildrequires
74 Additional BuildRequires for the package can be specified with this
75 setting. It accepts a line-separated / indented list of
76 BuildRequires in the syntax supported by RPM. The BuildRequires
77 included in this setting are either added in the
78 %generare_buildrequires scriptlet for targets where this is
79 enabled, or as plain BuildRequires for targets without dynamically
80 generated BuildRequires.
81 testrequires
83 This setting allows specifying additional BuildRequires that are
84 only needed when running a project’s test suite (i.e. "cargo
85 test"). It works the same as the setting for additional
86 BuildRequires, except that all entries are wrapped in an "%if
87 %{with check}" conditional.
88 lib.requires
90 With this setting, additional dependencies (Requires) for the main
91 "-devel" subpackage of a "library crate" can be specified. For
92 example, many "-sys" bindings require the development headers for
93 the wrapped C library to be present during both build time of the
94 package for the crate itself and when building a package that
95 depends on this crate. In these cases, the same dependency often
96 needs to be added as both buildrequires and lib.requires. This
97 setting accepts a list of line-separated / indented RPM
98 dependencies.
99 lib+foo.requires
101 This setting works just like lib.requires, except for adding
102 additional dependencies to subpackages for crate features. It can
103 be specified multiple times, and dependencies listed for "foo" are
104 added to the "-devel" subpackage for feature "foo" instead. Only
105 valid feature names are accepted, specifying a non-existent feature
106 will cause a validation failure.
107 bin.requires
109 For crates that include application binaries / executables, this
110 setting can be used to add additional dependencies for the
111 subpackage that contains these executables. The accepted values are
112 line-separated / indented strings that are valid RPM dependencies.
113
115 The rust2rpm.toml(5) configuration file format supports a superset of
116 the settings available in rust2rpm.conf, except that "layered"
117 configuration is not supported.
118 • summary: moved to the "summary" setting in the [package] table,
120 accepts a TOML string
121 • supported-arches: moved to the "supported-arches" setting in the
123 [package] table, accepts a TOML array of strings
124 • all-features: moved to the "enable-all" setting in the [features]
126 table, accepts a TOML boolean
127 • enabled-features: moved to the "enable" setting in the [features]
129 table, accepts a TOML array of strings
130 • unwanted-features: moved to the "hide" setting in the [features]
132 table, accepts a TOML array of strings
133 • buildrequires: moved to the "build" setting in the [requires]
135 table, accepts a TOML array of strings
136 • testrequires: moved to the "test" setting in the [requires] table,
138 accepts a TOML array of strings
139 • lib.requires: moved to the "lib" setting in the [requires] table,
141 accepts a TOML array of strings
142 • bin.requires: moved to the "bin" setting in the [requires] table,
144 accepts a TOML array of strings
145 • lib+foo.requires: moved to the "features" table in the [requires]
147 table, accepts a table with keys that must match feature names, and
148 TOML arrays of strings as values
149
151 Bindings for system libraries
152 One typical use case for a rust2rpm.conf file are in packages for
153 crates that contain bindings for system libraries, especially if crate
154 features are used to control which APIs of the library are made
155 available.
156 Example file from the package for "gtk4-sys" version 0.7.3 on Fedora
158 38, where version 4.10 of gtk4 is available:
159 [DEFAULT]
161 unwanted-features =
162 v4_12
163 v4_14
164 buildrequires =
165 pkgconfig(gtk4) >= 4.0.0
166 lib.requires =
167 pkgconfig(gtk4) >= 4.0.0
168 lib+v4_2.requires =
169 pkgconfig(gtk4) >= 4.2
170 lib+v4_4.requires =
171 pkgconfig(gtk4) >= 4.4
172 lib+v4_6.requires =
173 pkgconfig(gtk4) >= 4.6
174 lib+v4_8.requires =
175 pkgconfig(gtk4) >= 4.7
176 lib+v4_10.requires =
177 pkgconfig(gtk4) >= 4.10
178 External dependencies of the Rust standard library
180 The Rust standard library depends on some crates that are also
181 published separately, and a "hack" is used when building these crates
182 as part of "std". The crate features and optional dependencies that are
183 used for this purpose are useless in other situations.
184 Example file from the package for "libc" version 0.2.148:
186 [DEFAULT]
188 unwanted-features =
189 rustc-dep-of-std
190 rustc-std-workspace-core
191 buildrequires =
192 glibc-devel
193 lib.requires =
194 glibc-devel
195
197 https://pagure.io/fedora-rust/rust2rpm
198
200 rust2rpm(1), rust2rpm.toml(5)
201rust2rpm 2023-12-08 RUST2RPM.CONF(5)