On Wed, Nov 20, 2019 at 6:26 PM William Brown <wbrown@suse.de> wrote:
On 21 Nov 2019, at 09:45, John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
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.
Rust won't slow down though, and has no intent too. I think we have to accept it's fast moving.
Or, you know, someone could invest in becoming part of that community to provide counterweight, influence, and consideration for everyone else's needs. Maybe that's crazy?
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.
We can complain all we like here, but firefox is using rust, and other packages will use it too. We have to be able to adapt here ...
At this point, you're the only person actually complaining. You don't like what we've been working on, and as a developer of Rust software, you don't want to take the first step to be conscious of your target audience.
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?
They don't offer them support in these cases. This in mind SUSE/RH do support 'whole applications' like openshift, 389-ds or jboss, and "how those applications are composed" doesn't really factor into it, and they support them still.
That is not even close to true. And you should already know that, given that you *know* how the IdM/FreeIPA stack is developed, maintained, and supported.
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.
And that's fine, but we have to be able to support more than just that old model else we will be left behind.
This is weird, because this isn't the "new model", this model of development has been around forever. The problem is that it's bad at scale. We all know it is, with 25+ years of experience backing that up. That so-called "old model"? That was introduced to deal with the scaling problem. I'm sadly quite familiar with the Rust and Go ecosystems and I *know* nothing has changed in those ecosystems to make this better.
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. At this point, you just want permission to do something that's clearly not allowed in openSUSE policy. 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. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org