On 11/22/19 9:38 AM, 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] [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.
Yes and we do things like this with many python applications because its what customers expect. The cloud team invests significant resources into this area and maintain a significant number of python applications.
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.
This would be somewhat easier to do if people were using rust in a similar way just for containerized applications. Unfortunately this is not strictly how rust is being used, its starting to be used in core system libraries like librsvg which means that at least in some cases we have to think of it in the traditional mindset. The reason customers buy SLES is because they want a base system that doesn't change, many already think there are some parts of the base system that they think we update too often, and many get grumpy with us on the odd occasion when we have to ship a version update instead of backporting security updates. I won't argue against vendoring being a significantly easier and less effort at the same time though its not what our customers expect which is why SUSE's engineering department invests significant resources into not vendoring. Its not uncommon for SUSE Engineers to contribute patches upstream to projects adding options to the build system to use the system version of libraries not the vendored ones. As Rust usage increases this is something SUSE will have to deal with but where and how they allocate resources will be up to them, if the amount of effort required to manage the parts of the rust stack that your packages are likely to maintain is more then you have time for then that is a concern you should be raising with your manager. It wouldn't surprise if as rust usage grows SUSE needs to end up hiring a dedicated maintainer / maintainers for it, in the same way we have specific maintainers looking after the python / java / etc stacks for the whole distro. I can understand that there are probably other things you could be better spending your time on then maintaining Rust, but that doesn't mean we should just give up on dealing with it properly and finding a proper solution. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B