added a section to the readme about the collapse_features setting, why it exist and how to use it
Alexander Kjäll
1 year, 7 months ago
225 | 225 | obvious so documentation is less necessary, and dependent crates all do it |
226 | 226 | correctly already.) |
227 | 227 | |
228 | Setting collapse_features in debcargo.conf | |
229 | ------------------------------------------ | |
230 | ||
231 | Rust and Debian have a two different levels of abstraction when handling dependencies and the | |
232 | relationship between them. In rust the lowest level is a feature, and in Debian it's the binary | |
233 | package. | |
234 | ||
235 | This means that the following dependency chain is not a problem in rust: | |
236 | ||
237 | - crate A with feature AX depends on crate B with feature BY | |
238 | - crate B with feature BX depends on crate A with feature AY | |
239 | ||
240 | This is a perfectly valid situation in the rust+cargo ecosystem. Notice that | |
241 | there is no dependency cycle on the per-feature level, and this is enforced by | |
242 | cargo; but if collapse_features is used then package A+AX+AY would cyclicly | |
243 | depend on package B+BX+BY. | |
244 | ||
245 | This is reflected in the Debian packages by producing `Provides` lines for all combinations | |
246 | of features, and this can become a quite large section. | |
247 | ||
248 | Setting `collapse_features = true` in debcargo.toml removes this behaviour and is recommended, | |
249 | but it can lead to dependency cycles of debian packages, if that happens those must be | |
250 | broken up by having some or all of the packages set this feature to false. | |
251 | ||
228 | 252 | Changed orig tarballs |
229 | 253 | --------------------- |
230 | 254 |