The Rust Programming Language

Edit Package rust

NOTE: Builds using Rust bundled LLVM require upwards of 50GB.

Rust is a systems programming language focused on three goals: safety, speed, and concurrency. It maintains these goals without having a garbage collector, making it a useful language for a number of use cases other languages aren’t good at: embedding in other languages, programs with specific space and time requirements, and writing low-level code, like device drivers and operating systems. It improves on current languages targeting this space by having a number of compile-time safety checks that produce no runtime overhead, while eliminating all data races. Rust also aims to achieve ‘zero-cost abstractions’ even though some of these abstractions feel like those of a high-level language. Even then, Rust still allows precise control like a low-level language would.

Refresh
Refresh
Source Files (show merged sources derived from linked package)
Filename Size Changed
README 0000000079 79 Bytes
rust-rpmlintrc 0000000103 103 Bytes
rust.changes 0000164323 160 KB
rust.spec 0000003365 3.29 KB
Comments 14

Ben Ma's avatar

Hi, I wonder if there's any plan to add musl target support for rustc?


Luke Jones's avatar

It would be nice to have, but it also depends on my available time.


Guillaume GARDET's avatar

Could you wipe binaries for openSUSE_Factory_ARM/armv7l please? It should allow to use binaries from Factory:ARM


James Hodgkinson's avatar

Could you please build rust for arm on opensuse tumbleweed?



David Adam's avatar

Would you have any interest in adding further repositories for non-SUSE platforms? We'd like to distribute a recent-rust-using package for Debian/CentOS as well as openSUSE, and although I can build my own repository it seems to me that we wouldn't be the only project interested in doing so. I appreciate how to do so may be a challenge.


William Brown's avatar

There are a few thoughts in my mind here. The first is "what are you trying to achieve". Generally the view we have here is that rust packages are for "building stuff in the distro" rather than "for users/developers to build things". So is there a reason you can't use the centos/debian rust packages "as they are" for building things? Is there a reason you can't use rustup or similar?

The second is support / making sure it works. Centos is one thing, it's similar enough and uses rpm so it's probably not so bad. Debian on the other hand, it's packaging is really really complicated and I've never managed to work out how to make it ... well, do anything. So I don't really have the time - or interest - to try to make anything work with debian and it's packaging.

So I think were we to add other distros, they would be "occasional effort" at most, and not something I have a lot of time to support with sorry. But I'm not going to say "no" if someone else wants to put that effort in.


David Adam's avatar

Thanks. What I'm trying to achieve is to build native packages for distributions using OBS (in this case for shells:fish). We use OBS to build RPMs and dpkgs for a stack of platforms, and we remain very grateful for the ability to do so. However, my understanding is that it is not appropriate to upload prebuilt binaries to OBS for distribution (very reasonable), and the distro versions of rustc are often a long way behind state-of-the-art. I also believe the build VMs don't have internet access so rustup is not usable either. Maybe I'm wrong?


William Brown's avatar

Aaaahhhhh I see now. So you want to have it so you can build shells:fish with the latest rust because the distros are behind. Okay in that case "packaging for those other distros" is the right thing here for you then.

I think centos will be pretty easy, if not "already just works". Debian will be challenging though :(

If you branch and get it working there with latest centos/debian we can work out what needs to change in d:l:r for it to be committed. Does that work?


David Adam's avatar

Sure, I'm happy to give it a crack. I think it has to be done by building 1.x+1, x+2, etc where x is what's the latest in the distribution, so it might take a while.


William Brown's avatar

It doesn't :) Have a look at what we do in our .specs - we actually use the latest upstream binary as the bootstrap source, rather than the whole N, N+1, N+2 shenanigans.


David Adam's avatar

Oh, as long as that's ok by OBS policy, it's easy then.


William Brown's avatar

It's what we've been doing for years, so it has my tick of approval :)


William Brown's avatar

PS: william.brown at suse.com if you want to email me about it rather than OBS comments.

openSUSE Build Service is sponsored by