This essentially means we are always at the whims of those vendored dependencies and what they require, and that is highly likely to be the "latest" stable compiler.
I think we should aim to:
* Have rustc/cargo move with the upstream cadence, with automation as suggested into all SLE/LEAP/TW/Other
+1, I think that this is a good starting point.
Neal, what do you think of the idea from Ludwig of having a system rust compiler (more stable and conservative, used to build all the openSUSE rings), and a updated version of the compiler co-installable for developers.
It's not a _terrible_ idea. The only problem with it is that Firefox forces Rust to move forward anyway. That's why RHEL doesn't do this right now, either.
This isn't viable - the moment I, a developer, take my project from development -> packaging, I'm now on an older compiler that my dependencies won't compile with. They have to be the same version, and they have to both move at the rate upstream rust is moving as many dependencies really do move at that cadence too. This is even more important when you remember that rust doesn't distinguish security releases from feature ones, so an update to a dependency for security, may require newer compiler versions.
As much as we want to wring our hands and slow down rust, and do things "our way" we can't - we have to follow and adapt in this case.
So where do we start to start to achieve this?
You are making very hard questions : ))
Yes - because I want kanidm in opensuse at some point, and 389-ds is about to pick up rust as a requirement which will absolutely affect future leap versions. I want (need?) this solved. :)
I am personally in a phase that I try to have a view of what we want, and what are the good decisions. Fedora and Debian communities are spending a lot of thinking here, so before moving I want to have more information.
The assumption here is that Rust needs to be slowed down. That's not the case at all. You can move fast _without_ breaking things. The problem is that today there are no Rust compiler and language developers who understand this and help factor that into the future development of the stack.
I think that again, Rust has different targets (containers, static applications, continual integration and release) than an OS packaging system (shared libs, C, patched backports). It's not that they don't understand as much as they actively chose to follow a different path. Which is why we are struggling. The mental model of how we did things with C based programs doesn't apply. For years Red Hat / Fedora have tried to for python to be packaged like it's C, when it's not (which has left pip/pypi in bad places) and causes python on a system to be missing many libraries that do exist. This is why python as a community exclusively recommends virtualenv, not OS/system python. We'll probably end up in the exact same place with rust (cargo vs zypper in crate-foo). So we can either keep fighting against it, and people will just use cargo + vendoring anyway, or we can accept that the ship has sailed and try to work with it instead. For example: * https://build.opensuse.org/package/show/openSUSE:Leap:15.0/cargo * https://build.opensuse.org/package/show/home:gladiac/rav1e * https://build.opensuse.org/package/show/home:luke_nukem:rust_apps/nushell * https://build.opensuse.org/package/show/openSUSE:Leap:15.2/ripgrep
from M Matz:
That's a downside to QA process, not the packaging issue anymore. As far as I know we are discussing packaging right now, aren't we?
William (rightly) wants to have something realistic for the distro. Packaging (as in merely creating and submitting packages easily) is only one part, it can't be seen in isolation. If you can submit a thousand packages in 10 minutes doesn't really matter, if those thousand packages then don't land in Factory, or only six months after submission. The whole thing needs to work on all levels.
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. — 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