Packaging rust-lang

Josh Stone jistone at redhat.com
Thu Apr 30 23:43:56 UTC 2015


On 04/30/2015 02:56 AM, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 29 April 2015 at 19:15, Josh Stone wrote:
>> On 04/27/2015 02:35 AM, Fabian Deutsch wrote:
>>> Hey,
>>>
>>> there is some interest (the interested people are BCC'ed) in packaging
>>> [Rust](http://www.rust-lang.org).
>>> The packaging request is tracked here: Bug 915043 - Package rust (lang)
>>>
>>> There are two main parts to get the packaging done:
>>> (a) Get rust to use our pre-build llvm
>>> (b) Package the smaller dependencies
>>
>> Also important:
>> (c) Bootstrap requires a binary stage0 rustc
>> (d) There are essentially no ABI promises.
>>
>> I think stage0 is unavoidable, but does this need fesco approval?
> 
> No, but please file a tracking ticket with the FPC:
> 
> https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries#Bootstrapping
> 
> https://fedorahosted.org/fpc/

Does a static precompiled rustc count as a "bundled library" here?

I also wonder about this requirement:

"Packages which are built in such a bootstrapping mode must not be
tagged for a final release (or pushed as an update for any stable release)."

AFAIK rust *always* bootstraps for every build, and has particular
expectations about what level that stage0 rustc is at.  I think you
can't even expect to start over using the rustc you just built, because
some cfg(stage0) might be expecting an older state.

But maybe that kind of thing will fall away for released version, and
then "configure --enable-local-rust" will work -- not sure.

At least that stage0 is never part of the installed result, so it may
not actually matter as far as bundling is concerned.

>> I think the ABI means we can't really ship shared libraries, only static
>> rlibs.  Even when the hashed filename is the same, the symbols often
>> change, nevermind actual compatibility.
>>
>>
>> Cargo is also important for truly saying we've packaged rust.  But that
>> also has a bootstrapped binary, and comes with a whole heap of
>> dependencies.  And since there's no real way to use installed libraries
>> from cargo yet[1], apart from rustc's own libraries, all these pretty
>> much have to be bundled.
>> [1] https://github.com/rust-lang/cargo/issues/1334#issuecomment-76880322
>>
>>
>> Thoughts?
> 
> They need Bundled Library Exception from the FPC. Given the lack of ABI
> stability, I don't think it makes sense to package anything more beyond
> the compiler unless you wish to rebuild the (rust) world with every
> update of the compiler (if I understand the above correctly).

Cargo is integral enough that it really ought to be included.  All its
bundled libraries will have to be linked statically.

But I agree in general -- without ABI we can't expect to package rust
libraries.  It's possible some rust-implemented library could export
C-compatible functions, which is ok, but not rust-native.
e.g. http://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html



More information about the devel mailing list