Mailinglist Archive: opensuse-packaging (97 mails)

< Previous Next >
Re: [opensuse-packaging] On how to improve Rust packaging experience for suse
  • From: Neal Gompa <ngompa13@xxxxxxxxx>
  • Date: Wed, 20 Nov 2019 23:17:49 -0500
  • Message-id: <>
On Wed, Nov 20, 2019 at 6:26 PM William Brown <wbrown@xxxxxxx> wrote:

On 21 Nov 2019, at 09:45, John Paul Adrian Glaubitz
<adrian.glaubitz@xxxxxxxx> wrote:


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
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
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
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
based programs doesn't apply.

Using stable APIs and not updating hundreds of packages just because you
to install a newer version of Firefox or some security updates isn't the
model of C. It's the mental model of sanity.

We simply can't simply use the Rust release model for enterprise
because no matter what Rust upstream will claim: New upstream versions will
always bring regressions, in one way or another. Changing command line
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

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
how software is used in production environments. If 90% of the developers of
an upstream projects are running distributions like Fedora Rawhide, Arch
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
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
we will have to stick to the "old model" and that ship isn't going to sail

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >