Rust January 2017

rust@lists.fedoraproject.org

5 participants
4 discussions

Our first SIG meeting (2017-02-01)
by Igor Gnatenko 01 Feb '17

01 Feb '17

We do have meetings every Wednesday at 21:00:00 UTC on #fedora-meeting. Current plan is described here: https://pagure.io/fedora-rust/sig/pull- request/1. Don't hesitate to raise different topics which you would like to discuss and join meeting! P.S. no wiki and other stuff from 90's, only modern technologies https://fedoraproject.org/wiki/SIGs/Rust#Meetings -- -Igor Gnatenko

1 1

Rust SIG? Count me in!
by Fabio Valentini 30 Jan '17

30 Jan '17

Hi Guys, I've been interested in Rust for some time now (and even more, now that I've learned about functional programming and studied the lambda calculus at university ;) I have 2 questions regarding the state and future of Rust on fedora: 1) Is there support for building and distributing rust libraries as shared libraries (.so files), if the crate supports it? If not, this could lead to at least one problem ... any software package using a rust library via a FFI (as described at [0]) would have to build the crate itself and bundle the library. I don't think this is feasible in the long run (every package having to build the create itself and every package having to include the .so file looks like a lot of wasted work, time and space to me). Additionally, I generally dislike linking everything statically (like golang does), and would much prefer if fedora supported building and distributing rust libraries from the start. ;) 2) Is there a tool for generating .spec files / srpms from crates (like gofed, but nicer), and is such a tool planned? If nobody has started working on that yet, I'd volunteer. It sounds like a fun project! [0]: https://doc.rust-lang.org/1.5.0/book/rust-inside-other-languages.html Fabio

4 10

Boolean dependencies vs self-provides (for rust "features" support)
by Igor Gnatenko 30 Jan '17

30 Jan '17

```toml [dependencies] bitflags = "~0.7" ansi_term = { version = "~0.9.0", optional = true } term_size = { version = "~0.2.0", optional = true } libc = { version = "~0.2.9", optional = true } [features] default = ["color", "wrap_help"] color = ["ansi_term", "libc"] wrap_help = ["libc", "term_size"] ``` Since we are packaging source code, -devel package will have `Requires: crate(bitflags)`. But applications (which are built out of this sources statically) can request features which this source is exposing and it means that it should pull additional dependencies. Syntax for such dependencies is like: ```toml [dependencies] clap = { version = "2.19.2", features = ["yaml"] } ``` Obviously, first thing which is coming to mind is to specify provides for features and use rich dependencies for requirements, something like: ``` Provides: crate(clap) Provides: crate(clap)(color) Requires: ((crate(ansi_term) and crate(libc)) if crate(clap)(color)) Provides: crate(clap)(wrap_help) Requires: ((crate(libc) and crate(term_size)) if crate(clap)(wrap_help)) ``` But it doesn't work since it works the RPM thinks that crate(clap)(xxx) is going to be installed (since it's provided by same package) so it requires other packages to be installed as well which is something not what we want. Probably for now sane way would be just require all optional packages to cover *all* features which package provides, but it means that builds will be slow because they would need to pull a lot of packages always. P.S. I omit version stuff to make examples more easy. P.P.S. ignore `default` feature for now since I'm not sure how exactly it works in rust/cargo ecosystem at this moment. -- -Igor Gnatenko

2 2

Automatic BuildRequires
by Igor Gnatenko 29 Jan '17

29 Jan '17

This topic is not very much interesting for C/C++/D/etc. languages, but very interesting for Python, Ruby and Rust ecosystems. In those ecosystems you can get build-time and test-time dependencies very easily since metadata is pre-populated (doesn't matter how) and you just need to parse it, but RPM doesn't support generating BuildRequires. As we discussed some time ago with Panu and Florian on IRC this task splits to 2 different blocks: 1. Pre-BuildRequires -- everything what needs to be installed in order to unpack archive and parse metadata 2. Make building of SRPM a bit more tricky: first time to build something what can gather builddeps and then generate full SRPM with all that stuff. I was thinking a bit if we should really make different section for only for generating builddeps (as Panu was asking) and I think it's not needed and we can (or probably even should) reuse -- for example, upstream provides wrong metadata (redundant requires or very strict version which you want to relax), you do sed/patch in %prep and it should be both same for BuildRequires generation and for real build. Another question here as well is how do you generate test builddeps: since we don't have BuildRequires(check), we probably would need to have BuildRequires and TestRequires generator... but I'm not sure how to wrap it properly. Thoughts? -- -Igor Gnatenko

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Rust January 2017