On 25 Nov 2019, at 19:45, Richard Biener <rguenther@suse.de> wrote:
On Fri, 22 Nov 2019, William Brown wrote:
On 22 Nov 2019, at 03:04, Alberto Planas Dominguez <aplanas@suse.de> wrote:
On Thursday, November 21, 2019 8:40:19 AM CET Richard Biener wrote:
[cut a lot here]
From the start of the thread I remember there were two conflicting things - first packaging where vendoring seems to work and while it's not ideal it's probably going to be what we need to do due to being "slow". I interpret your above sentences as that this is intended to work this way.
Then there's the need of a developer using Rust (but not necessarily packaging software for a distro) who wants the latest and greatest. I've suggested we provide means to easily bootstrap such upstream Rust - and you've indicated that yes, indeed, thats supported and even the way it is supposed to work, but there's no openSUSE "package" to start this (in Factor).
What is wrong on the idea of having two compilers: the system one used for the distribution, and the one that can be updated and expected to be used by developers.
Another idea is to have one single compiler, the system-wide one, and provide a rustup binary that the developer can use to install rust and cargo on the users $HOME. Dany Marcoux already submitted the package, but later was closed.
I personally prefer the 2 compiler idea, tho, but this is irrelevant.
The 2 compiler idea is kind of a problem? I have a version on my machine that I was developing with (1.39.0), and encountered version (1.36.0) on leap which didn't have a feature I required.
Of course this happens with C++ language features evolving as well. And we _do_ have multiple(!) GCC C++ compilers around, also specifically to address this problem. So I see no problem with having multiple rust compilers around.
It's not the presence of multiple compilers thats a problem, it's the rules around them. C really hasn't changed much - new gcc versions fix bugs or work faster etc. It's not a big deal. Rust compiler versions introduce large, changing feature sets, that really affect the usage of the language. This year alone I think maybeuninit, async/await, try_from all come to mind. The issue is that what we ask developers to use (latest and greatest, all upstream deps) is in conflict when we go to package those software into suse which will use a "stable" compiler (older version, ie missing features) because those upstream dependencies will latch onto those new features very quickly. There are already upstream crates that won't compile with a 6 month old compiler - let alone 1 year or more. I think my point is that I want the path from developer to packager and maintainer to be simpler and laid out, and our ecosystem supporting that instead of throwing up barriers or hurdles. It's also worth bearing in mind that rust does not have most of the issues which makes C developers so anxious or conservative around versioning and releases. As mentioned, rust is closer as an experience to docker than C. — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org