Mailinglist Archive: opensuse-packaging (97 mails)

< Previous Next >
Re: [opensuse-packaging] On how to improve Rust packaging experience for suse

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,
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
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.

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
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 ...

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 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

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
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

And that's fine, but we have to be able to support more than just that old
model else we will be left behind.

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
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

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".


William Brown

Senior Software Engineer, 389 Directory Server

To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups