On Wed, 20 Nov 2019, Neal Gompa wrote:
On Wed, Nov 20, 2019 at 6:26 PM William Brown <wbrown@suse.de> wrote:
So the more I'm reading into this thread the more I think that my conclusion here is:
* We should have rust/cargo's release cadence seperate from the release cycles of a distro (ie fedora modularity in a way, or tw style) * Packaging crates to rpms is not feasible or scalable, and we should not attempt it - cargo already has vendor and all the packages I've seen in obs today use vendored dependencies. * We should instead focus on packaging "edge" programs that use rust IE firefox, ripgrep. * Focus pkg QA efforts on the edge packages * We could consider integration of tools like cargo-audit to scan for security issues in packages (similar to clamav in obs already) to help ensure vendored deps are "up to date". * Improve the rpm spec docs related to rust/cargo to help make it easier for people to give us packaged programs.
It could also happen that certain software projects like librsvg or 389-ds are being forked in their last non-Rust version to avoid the bootstrap issues. It's not that projects haven't been forked in the past over such fundamental project philosophy issues (XFree86/X.Org, libav/ffmpeg, OpenOffice/LibreOffice, eglibc/glibc, ecgs/gcc etc).
I don't think the hammer method that some projects are currently using to push Rust is going to be successful in the long-term.
As the person who is adding rust to 389-ds, the maintainer of it at suse, and part of the upstream team (the rh people are also on board with this), I don't think I'll be forking "the last non-rust version" as that would be a bit self defeating ...
We need productive solutions, not complaining that rust is different to "how it's always been".
Alright, I'm going to come out and say it. You need to pull that stick out of your rear.
What gives you the right to be so arrogant as to think that you're better than everyone else who has been talking in this thread, and the 5+ people working on the Rust ecosystem across *three* distributions?
We already update the Rust compiler stack as fast as we can, and quite frankly, you should be *happy* we do this with basically no involvement from you, the *only* person I know of at SUSE doing *any* meaningful Rust development work. Moreover, you are *paid* to consider SLE and openSUSE Leap (and to a lesser extent RHEL and CentOS) as targets for your code work. That means *you* must work with the restrictions you have. Cargo is perfectly capable of giving you dependencies that work for your version of the Rust compiler. I've done Rust development work, you *don't* need the latest Rust compiler all the time. You are not developing anything that needs it. Your dependencies are no excuse, as you can control those and use versions that work with your Rust language compiler that you have available.
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).
At this point, you just want permission to do something that's clearly not allowed in openSUSE policy.
Now I didn't follow the thread too closely so I don't remember what the issue is. I believe policy is made by the openSUSE developers so there is (and should!) be flexibility here.
Well, I'm not going to give you that blessing. I know we have a whole bunch of people violating the rules with various ecosystems (Java, Go, Rust [for now], etc.). That does not make it okay. That just means the openSUSE review team doesn't care enough to block them right now. There is no rules that expressly permit this, so guess what? That means someone could decide to care and rip all those packages out.
Stop being rude and start being constructive.
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. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)