Mailinglist Archive: opensuse-packaging (97 mails)

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

On 19 Nov 2019, at 10:43, William Brown <wbrown@xxxxxxx> wrote:

On 19 Nov 2019, at 10:39, Neal Gompa <ngompa13@xxxxxxxxx> wrote:

On Mon, Nov 18, 2019 at 6:58 PM William Brown <wbrown@xxxxxxx> wrote:


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

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

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?

Unfortunately, SUSE rust compiler packaging spec isn't the same as the
RH/Fedora/Mageia one, so essentially it takes double the work to keep
things up to date everywhere. If we integrated the SUSE support bits
into the RH/Fedora/Mageia rust packaging spec, that could make things
easier. It's not exactly the highest thing on my list to look into
right now, though...

That said, Fedora and Mageia update the Rust compiler within a week of
a new stable compiler release. As of right now, Fedora 29 and higher
all have Rust 1.39.0. CentOS/RHEL 7 will receive Rust 1.39.0 soon

Hmmmm, I'm seeing that on Fedora 30 on OBS that this is failing due to a lack
of try_from:

So this indicates that our Fedora 30 in obs may not be getting these updates?

Okay, so when you do:

Project -> Repositories -> Add from a distribution -> select fedora 30

That only adds fedora 30 standard:

But not update. This is why all the f30 builds I have are failing. This seems
like a bug or error to me.

Crate packaging and macros are completely in sync among Fedora,
Mageia, and openSUSE. These are provided by the rust-packaging and
rust-srpm-macros packages. This code is pretty much the same across
all three distributions.

I find the process of shipping updates to SUSE distributions
thoroughly annoying and unappealing, so I don't personally do anything
to target anything other than Tumbleweed. The process is too slow
because it's often bottlenecked on either legal-auto or the
all-too-tiny number of reviewers for SRs and MRs. This is also true
for Tumbleweed, but it seems to be somewhat faster there. I'd be more
interested in helping ship updates to Leap if we could make this
process less awful.

I think this process has to become less awful, else we'll be missing out on
plenty of rust tooling that is quickly coming available for platforms.


真実はいつも一つ!/ Always, there's only one truth!


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


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