On 08/21/2017 07:20 AM, Christian Stadelmann wrote: > I'd like to see this change land in F28! > > Anyway, I think there is a showstopper: > * Fedora Packaging guidelines demand packages bundle no dependencies (e.g. > libraries, or in Rust's case crates). This is a good choice in my opinion. > * Rust currently has no ABI definition compatible over different versions of > the rust compiler. As a result, every time a new compiler is released it will > also require *ALL* rust packages to be rebuild. See > https://github.com/rust-lang/rfcs/issues/600 for details and discussion. > * To get a sane update strategy, it is critical that not too much packages > are involved in rebuilds. Consider a CVE in openssl: Luckily we can rebuild > openssl (plus its subpackages) and ship it. No need to rebuild every > application that uses openssl or uses another package which uses openssl. > > As far as I understand, these 3 points are conflicting right now. Either Rust > gets an ABI or we need to give up one of the other two principles, which I > highly recommend not to do. > > Disclaimer: I'm no Rust expert, nor am I an ABI expert, so I might be > completely wrong about this.
These package guidelines are exactly meant to solve the bundling question, so we can package crates separately. So it's more of a problem of static or dynamic linking. Since there's no Rust ABI, we can't support shared libraries for Rust interfaces. So all crates will ship source-based devel packages, and applications statically link these. The only Rust shared libraries we'll have at all are those from the compiler and standard library, which are explicitly filtered from Provides. Their only use for other packages is in transient build scripts and plugins, which don't get installed. For FFI to libraries like openssl, it's still expected to use dynamic linking. And in the other direction, if a Rust library provides a C ABI (a "cdylib" crate type), this is dynamic too. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
