Bug 1374006

Summary:	Please split into separate packages for compiler and runtime library
Product:	[Fedora] Fedora	Reporter:	Christian Stadelmann <fedora>
Component:	rust	Assignee:	Josh Stone <jistone>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	24	CC:	jistone
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-09-07 19:39:00 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Christian Stadelmann 2016-09-07 16:16:17 UTC

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.

Comment 1 Josh Stone 2016-09-07 17:14:22 UTC

[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.

Comment 2 Christian Stadelmann 2016-09-07 19:39:00 UTC

Ok, you're right, I completely forgot about the ABI stability issue. Sorry for the noise.