Mailinglist Archive: opensuse-packaging (97 mails)

< Previous Next >
Re: [opensuse-packaging] On how to improve Rust packaging experience for suse
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�������Ǩ�
< Previous Next >
Follow Ups