Mailinglist Archive: opensuse-packaging (97 mails)

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


On 11/22/19 9:38 AM, William Brown wrote:


On 22 Nov 2019, at 03:04, Alberto Planas Dominguez <aplanas@xxxxxxx> wrote:

On Thursday, November 21, 2019 8:40:19 AM CET Richard Biener wrote:

[cut a lot here]
[more cut]
Indeed. We're not going to make Rust "go away". Vendoring works
fine enough for "leafs" like Firefox but indeed having the rust
stack in core components imposes some scalability issues and
people should think twice before introducing a rust dependency
into, say, systemd. But obviously those who do the work decide,
and as alwaks talk is cheap.

I am sorry but... vendoring is not working. OBS is not aware of what is
inside, so any security update in any component in the closure can hurt us a
lot.

I'd suggest we wont be able to stop people vendoring because the rate of flux
in crates.io is so high, continually adding and packaging more crates is
going to be a high resource cost on people. If I had to submit 200 rpm's to
suse just to submit kanidm, I'd probably give up at the sheer thought of that
effort on me and others.


Yes and we do things like this with many python applications because its
what customers expect. The cloud team invests significant resources into
this area and maintain a significant number of python applications.

Security updates become a requirement of the projects submitting to ensure
their vendored dependencies are up to date. I think that we can detect this
with cargo audit as a build step in the spec instead, similar to how we use
clamav.


I guess the feeling I'm getting overall from this thread and peoples input is
the idea of "support" and what that is, and how it works, and what goes into
that.

SUSE/SLE/Distros have always been about supporting "layers", such as a kernel
or tls library. They are updated dynamically and the higher layers can
inherit their changes seamlessly. This encourages backporting, patches etc.
They also have C compilers that have *rapidly* changed in the last two
decades, which while making code "faster", has also introduced (sometimes
breaking) changes when you recompile the same code. This unpredictability
makes us want to stick to a known compiler for a version so that all the
layers are consistent. It means you have to have these layers work for
multiple applications at the same time, via ABI's that are "stable". This
promotes us keeping one version of a layer part that is supported for a long
time.

Rust, firefox, docker and others, have become about supporting
"applications". The interface is no longer between layers, but the
user-facing parts, and the application as a whole is a "static linked" whole
stack that is supported as is. The composition of that static application is
the responsibility of the project, who is expected to re-build and re-release
often. Rust has no ABI or guarantees about it, shifting this to compile time
rather than link time to ensure you consume the API correctly. A single
project can have multiple versions of the same crate in it's dep stack (rand
is a key example here, in large projects it's been observed to have 4
different api versions). This in mind, due to Rust's guarantees many of the
memory safety issues that heavily affect C do not exist, meaning there are
less stability and security releases in comparison, and that static stack is
much more reliable as a whole, lending again to supporting the "application"
as a whole unit rather than supporting the "layers" that make it up.


I guess maybe we should think about Rust applications the same way we think
about docker applications, they have much more in common as staticly linked
units than say comparing Rust to C.


This would be somewhat easier to do if people were using rust in a
similar way just for containerized applications. Unfortunately this is
not strictly how rust is being used, its starting to be used in core
system libraries like librsvg which means that at least in some cases we
have to think of it in the traditional mindset.

The reason customers buy SLES is because they want a base system that
doesn't change, many already think there are some parts of the base
system that they think we update too often, and many get grumpy with us
on the odd occasion when we have to ship a version update instead of
backporting security updates.

I won't argue against vendoring being a significantly easier and less
effort at the same time though its not what our customers expect which
is why SUSE's engineering department invests significant resources into
not vendoring. Its not uncommon for SUSE Engineers to contribute patches
upstream to projects adding options to the build system to use the
system version of libraries not the vendored ones.

As Rust usage increases this is something SUSE will have to deal with
but where and how they allocate resources will be up to them, if the
amount of effort required to manage the parts of the rust stack that
your packages are likely to maintain is more then you have time for then
that is a concern you should be raising with your manager. It wouldn't
surprise if as rust usage grows SUSE needs to end up hiring a dedicated
maintainer / maintainers for it, in the same way we have specific
maintainers looking after the python / java / etc stacks for the whole
distro. I can understand that there are probably other things you could
be better spending your time on then maintaining Rust, but that doesn't
mean we should just give up on dealing with it properly and finding a
proper solution.

--

Simon Lees (Simotek) http://simotek.net

Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

< Previous Next >