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. What I'm thinking is important is how can we encourage developers to want to package their code for suse. Developers will use whatever is latest in crates.io (and sometimes wont have a choice due to indirect dependencies), and as I've mentioned, there is a strong trend for those dependencies to always rely on latest stable features. Having a 4 month old (or older) version will become a blocker to adding software (or rust security updates) to suse :(
[more cut]
Indeed. We're not going to make Rust "go away". Vendoring works fine enough for "leafs" like Firefox but indeed having the rust stack in core components imposes some scalability issues and people should think twice before introducing a rust dependency into, say, systemd. But obviously those who do the work decide, and as alwaks talk is cheap.
I am sorry but... vendoring is not working. OBS is not aware of what is inside, so any security update in any component in the closure can hurt us a lot.
I'd suggest we wont be able to stop people vendoring because the rate of flux in crates.io is so high, continually adding and packaging more crates is going to be a high resource cost on people. If I had to submit 200 rpm's to suse just to submit kanidm, I'd probably give up at the sheer thought of that effort on me and others. Security updates become a requirement of the projects submitting to ensure their vendored dependencies are up to date. I think that we can detect this with cargo audit as a build step in the spec instead, similar to how we use clamav. I guess the feeling I'm getting overall from this thread and peoples input is the idea of "support" and what that is, and how it works, and what goes into that. SUSE/SLE/Distros have always been about supporting "layers", such as a kernel or tls library. They are updated dynamically and the higher layers can inherit their changes seamlessly. This encourages backporting, patches etc. They also have C compilers that have *rapidly* changed in the last two decades, which while making code "faster", has also introduced (sometimes breaking) changes when you recompile the same code. This unpredictability makes us want to stick to a known compiler for a version so that all the layers are consistent. It means you have to have these layers work for multiple applications at the same time, via ABI's that are "stable". This promotes us keeping one version of a layer part that is supported for a long time. Rust, firefox, docker and others, have become about supporting "applications". The interface is no longer between layers, but the user-facing parts, and the application as a whole is a "static linked" whole stack that is supported as is. The composition of that static application is the responsibility of the project, who is expected to re-build and re-release often. Rust has no ABI or guarantees about it, shifting this to compile time rather than link time to ensure you consume the API correctly. A single project can have multiple versions of the same crate in it's dep stack (rand is a key example here, in large projects it's been observed to have 4 different api versions). This in mind, due to Rust's guarantees many of the memory safety issues that heavily affect C do not exist, meaning there are less stability and security releases in comparison, and that static stack is much more reliable as a whole, lending again to supporting the "application" as a whole unit rather than supporting the "layers" that make it up. I guess maybe we should think about Rust applications the same way we think about docker applications, they have much more in common as staticly linked units than say comparing Rust to 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