Mailinglist Archive: opensuse-packaging (97 mails)

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


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]

From the start of the thread I remember there were two conflicting
things - first packaging where vendoring seems to work and while
it's not ideal it's probably going to be what we need to do due
to being "slow". I interpret your above sentences as that this
is intended to work this way.

Then there's the need of a developer using Rust (but not necessarily
packaging software for a distro) who wants the latest and greatest.
I've suggested we provide means to easily bootstrap such upstream
Rust - and you've indicated that yes, indeed, thats supported and
even the way it is supposed to work, but there's no openSUSE "package"
to start this (in Factor).

What is wrong on the idea of having two compilers: the system one used for
the
distribution, and the one that can be updated and expected to be used by
developers.

Another idea is to have one single compiler, the system-wide one, and provide
a rustup binary that the developer can use to install rust and cargo on the
users $HOME. Dany Marcoux already submitted the package, but later was closed.

I personally prefer the 2 compiler idea, tho, but this is irrelevant.

The 2 compiler idea is kind of a problem? I have a version on my machine that I
was developing with (1.39.0), and encountered version (1.36.0) on leap which
didn't have a feature I required. What I'm thinking is important is how can we
encourage developers to want to package their code for suse. Developers will
use whatever is latest in crates.io (and sometimes wont have a choice due to
indirect dependencies), and as I've mentioned, there is a strong trend for
those dependencies to always rely on latest stable features. Having a 4 month
old (or older) version will become a blocker to adding software (or rust
security updates) to suse :(


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

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.


Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

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

< Previous Next >