Mailinglist Archive: opensuse-packaging (97 mails)

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


On 11/19/19 6:27 PM, Richard Biener wrote:
On Tue, 19 Nov 2019, William Brown wrote:

Hi,

Recently I've been trying to package some utilities for SUSE and Fedora via
OBS that are written in Rust. I'm running into a bit of a problem though.

Rust as a language has a very aggressive release cycle compared to what we
expect on a platform like SUSE - 6 weeks
(https://github.com/rust-lang/rust/blob/master/RELEASES.md). In each cycle
Rust releases new features, and despite the core language being "stable" and
safe (which is great!) new features tend to be used very rapidly by library
authors. For example the release from Version 1.34.0 (2019-04-11) contains
convert::TryFrom, which is now in use by a large number of libraries.

Rust also has an (unfortunate) requirement that you are essentially forced
to use cargo which is a build and dependency management tool. Cargo is
extremely opinionated and inflexible which makes it difficult to use.
However as it's also a dependency management tool, this has encouraged an
npm-style ecosystem of dependencies to spring up on https://crates.io/ - and
it's effectively the only way to use libraries in Rust. But additionally,
it's promoted a system where a library may have a large number of small
dependencies too.

Due to the fast release cycle, developers aggressively using new features,
and the npm style micro dependency system we have a recipe for problems - if
you are not using the latest stable compiler, it's extremely likely that
your libraries, or their dependents may not build on your project. Which is
exactly the issue I have run into where rust on fedora 30 and opensuse leap
15.1 are simply too old to support the features that have been used in the
last 6 months by library developers.


Which leads me to the question of "what to do".

* I don't believe it's feasible to ask Rust to "slow down". It's just not
going to happen, and they will keep adding features that people will "want"
to use.
* We can't expect people *not* to update their dependencies in projects as
that would prevent security updates being included. So we have to accept
projects that will use "latest and greatest" complier features somewhere in
their dependency graph.
* Which leaves distros (like us) speeding up our rust compiler cycle somehow.


For opensuse I can probably do something like adding devel:languages:rust as
a respository to my project. Would this strategy be viable on SLE? What
about for projects which we want to expose packages for fedora or other? Are
we able to have toolchains move faster than our base system?

I'm really looking for ideas on how we can sustainably use rust projects
within the governance and social constraints that exist in the space.
Ideas?

When facing issues like this we need to think whether having "packages"
for all of this is really a good fit for the purpose. I think it would
be appropriate to concentrate on enabling people to bootstrap/update
something like a /usr/local/rust "repository" (or $HOME/.rust?) with the
latest and greatest from upstream. This means providing rust/cargo (and
whatever else needed) packages plus scripting that will fetch, build and
install the newest releases. Trying to fit external ecosystems with
own "package management" into ours may not be the best way time is spent.

But not needing to go and download the "bootstrap binaries" from an
untrusted source is reasonable.

All this probably applies to other languages as well, though it may be
that there only the package management part is a problem there, not
too fast evolving core tools.

Unfortunately as parts of SLE start to make use of some of these
languages it becomes more complex then that. Many of the reasons we do
the things we do the way we do at the moment are that it makes our
compliance processes significantly easier (and in many cases possible at
all).

--

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