Hi! On 11/20/19 11:26 PM, William Brown wrote:
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.
But packages like 389-ds and librsvg are anything but typical container packages which is the main problem here. People don't necessarily criticize that Rust is fast moving target at the moment. They criticize that people start using Rust for system-critical components while Rust is a moving target.
Which is why we are struggling. The mental model of how we did things with C based programs doesn't apply.
Using stable APIs and not updating hundreds of packages just because you need to install a newer version of Firefox or some security updates isn't the mental model of C. It's the mental model of sanity. We simply can't simply use the Rust release model for enterprise distributions because no matter what Rust upstream will claim: New upstream versions will always bring regressions, in one way or another. Changing command line options or configuration file formats is already a regression in production use. No paying customer really wants to see an update breaking their whole server setup. It's simply not acceptable. Imagine SLE running in a critical system at a bank on an IBM zSeries mainframe responsible for millions of customers and then you start upgrade 250+ packages for a security fix and break the whole database.
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.
Again, this isn't a language issue. This is upstream projects not understanding how software is used in production environments. If 90% of the developers of an upstream projects are running distributions like Fedora Rawhide, Arch Linux or Tumbleweed, they naturally don't understand why you wouldn't want all packages to be bleeding edge all the time. But this isn't something you can use in a production environment with hundreds, thousands or even millions of customers.
This is why python as a community exclusively recommends virtualenv, not OS/system python.
So, how exactly do you expect SUSE or RedHat being able to support a paying customer when their whole Python environment has been installed through pip? Our engineers simply can't support a software environment that we have no control over. The main reason why software is being packaged in distribution besides convenience is being able to provide something that can be supported by the distribution vendor. If we just give our customers a minimal base system and just let them install all their software through cargo, pip, npm and what not, we won't be able to provide support for their environment. We might as well drop the concept of a distribution then. But that's when enterprise customers will return to proprietary systems like Windows Server or AIX.
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.
As long as we want to provide a distribution that we can provide support for, we will have to stick to the "old model" and that ship isn't going to sail anywhere.
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. Adrian N�����r��y隊Z)z{.��ZrF��x>�{.n�+������Ǩ��r��i�m��0��ޙ������� ��$j���0�����Ǩ�