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 |