Mailinglist Archive: opensuse-packaging (94 mails)

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


On 19 Nov 2019, at 20:43, Alberto Planas Dominguez <aplanas@xxxxxxxx> wrote:

On Tuesday, November 19, 2019 12:58:35 AM CET William Brown wrote:

That is funny, because I set myself to help (inside my modest skills) on both
projects (Rust and Kanidm) before this issue arise. As usual I am too late.

Never too late, would always be happy to have your input and advice :)


Anyways.

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 have a naive TODO:

1) Add in _service, script and / or document how to update rustc, and help
the
rustc maintaner in the update task more pro-actively

2) Add _service, script and document the upgrade of the crates, helping the
work that the Fedora guys are doing in openSUSE. I think that is time for
openSUSE to help here.

2.5) Research how the Haskel team is doing their magic, as IMHO is a good
example to follow.

3) Using some data-driven mechanism, decide the crates / version will live in
TW and the ones that will live only in the devel project. I am not sure how
to
tackle the multiversioning here.

I hope to automatize all the steps, and do the submit to TW incrementally, as
I am worried about the legal review.

The compiler (and crates) in Leap and SLE cannot follow this peace, but we
can
help upstream to crystallize the idea of 'reference / stable compiler
version'. Maybe we can skip 3 / 4 versions form TW to one in Leap.

For SLE we can use the backports. The managers can interlock later the
version
for SLE, based on the requirements on the software that they are shipping.

For Kanidm (and any project that uses Rust) this means that the devel version
can compile on TW every day, but for Leap and SLE the version of the project
and the compiler cannot change, and the fixes needs to be backported. This is
aligned with how every product works: release and backport the fixes.

The issue becomes fixes to vendored dependencies (of which there are ~200 I
think total. I directly have ~30 deps). Fixes to kanidm are simple to patch and
backport, but fixes for vendored code ... not so much. That's what will really
be the issue is rust has no concept of a security update vs a feature one - and
most crates treat them as the same - updates. So you will have a vendor library
that will both have security *and* feature changes, which will quickly be a
maintainers nightmare.


This can get more complicated with the crates. One usual solution in OBS is
to
create a subproject for an specific release of the project (lets say, for
example, Kanidm 1.0), and link the old version of the crate from
devel:languages:rust:crates to the new project.

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?

Neal Gompa wrote:

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
too[1].

The devel project was updated almost the same day in OBS. We (openSUSE)
submitted the new version, created the upstream bug report about the issue
that makes impossible the bootstrap of the compiler, and backported it to our
packages. I am not going to check Fedora nor Mageia, but if they need to
compile 1.39 with 1.38 (and later with 1.39) they need to use this patch.

openSUSE do not have it yet on TW because we recompile all the dependencies,
and this 1.39 is having issues with FF[1]. I am not sure if other
distributions ship the FF compiled with 1.3X and the rustc from 1.39
independently. We cannot do that: we need to fix the issues as we find them.

Simon Lees wrote:

One reason that it is done like this by default is because core SLE /
Leap packages shouldn't be break API/ABI for updates, so in the vast
majority of cases building against standard is fine and saves huge
amounts of resources on obs.

That is true. But as we cannot have ABI compatibility with rust (not stable
ABI and almost all is statically linked), I wonder if this will help to speed
the update of the compiler in SLE and Leap.

Neal Gompa wrote:

Rust in openSUSE is mostly community, driven within the Fedora Rust
SIG (Yes, Fedora Rust runs the openSUSE Rust stack). The Rust compiler
package does get semi-regular contributions from two SUSE employees,
but the bulk of the Rust stuff is through the Fedora Rust SIG.

: ? is Luke Jones from Fedora?

But in any case this is 100% true in the crates side. This is almost all done
by the excellent Fedora Rust SIG. I really think that it is time for openSUSE
to help here and with the upstream scripts from Fedora that is doing this
magic.

I want to do my part here.

I think to help (because I want to help here too), we need to think of
actionable ways forward. I think we need to think about what rust *should* look
like in suse, and work from that vision?


[1] https://build.opensuse.org/project/monitor/openSUSE:Factory:Staging:M?
arch_x86_64=1&defaults=0&failed=1&repo_standard=1
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nuremberg
Germany

(HRB 36809, AG Nürnberg)
Managing Director: Felix Imendörffer


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