The Rust Programming Language
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.
- Devel package for openSUSE:Factory
-
13
derived packages
- Links to openSUSE:Factory / rust
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout devel:languages:rust/rust && cd $_ - Create Badge
Source Files (show unmerged sources)
| Filename | Size | Changed |
|---|---|---|
| README | 0000000079 79 Bytes | |
| rust-rpmlintrc | 0000000103 103 Bytes | |
| rust.changes | 0000163289 159 KB | |
| rust.spec | 0000003175 3.1 KB |
Latest Revision
William Brown (firstyear)
(revision 346)
baserev update by copy to link target
Comments 14
Hi, I wonder if there's any plan to add musl target support for rustc?
It would be nice to have, but it also depends on my available time.
Could you wipe binaries for openSUSE_Factory_ARM/armv7l please? It should allow to use binaries from Factory:ARM
Could you please build rust for arm on opensuse tumbleweed?
Hey there, this is broken due to https://bugzilla.suse.com/show_bug.cgi?id=1196328
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.
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.
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?
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?
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.
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.
Oh, as long as that's ok by OBS policy, it's easy then.
It's what we've been doing for years, so it has my tick of approval :)
PS: william.brown at suse.com if you want to email me about it rather than OBS comments.