Hide Forgot
Description of problem: Currently, the "rust" package ships 1. rustc, rustdoc and librustc plus some dependencies 2. libstd plus dependencies In case a user just wants to install a rust application, he doesn't need rustc. Therefore, I suggest splitting the "rust" package into two separate ones, for example putting all the compiler stuff into a subpackage named "rust-compiler" or "rustc" Version-Release number of selected component (if applicable): 1.11.0-3.fc24 How reproducible: always – packaging Additional info: To make sure that rustc doesn't get uninstalled, be careful to change the SPEC file accordingly.
[bikeshed] I would probably leave it "rust" for the compiler, and make a new "rust-libs" for libraries needed by rust-compiled applications. And I have a TODO in the spec already to think about this for multilib purposes, so a 64-bit rustc could also target 32-bit apps - but that's not needed for the distro itself. However, as currently packaged we are not providing *any* runtime libraries. The only *.so files included are just used for rustc and rustdoc, and these libraries are explicitly filtered from rpm provides to anybody else. Then rustlib/$target/ only has *.rlib static libraries, so it shouldn't be possible to dynamically link any part of libstd. Rust has no stable ABI at all. It will certainly break between compiler versions, and may even break in subtle ways if we ever need to patch a given version in Fedora. Thus, I believe static linking is the only feasible option for Rust packaging at this time. You can follow this issue for Rust ABI: https://github.com/rust-lang/rfcs/issues/600 That said, Rust packages should certainly link dynamically to FFI libraries, as rust currently does for libc and llvm, or cargo does for openssl, curl, and libgit2. I'm inclined to close this as WONTFIX or even NOTABUG, but I'm open to your response first, if you have anything to add.
Ok, you're right, I completely forgot about the ABI stability issue. Sorry for the noise.