Mailinglist Archive: opensuse-packaging (97 mails)

< Previous Next >
Re: [opensuse-packaging] On how to improve Rust packaging experience for suse
On Wed, Nov 20, 2019 at 4:48 AM Alberto Planas Dominguez
<aplanas@xxxxxxx> wrote:

On Wednesday, November 20, 2019 12:53:06 AM CET William Brown wrote:
On 20 Nov 2019, at 05:57, John Paul Adrian Glaubitz
<adrian.glaubitz@xxxxxxxx> wrote:
On 11/19/19 7:15 PM, Jan Engelhardt wrote:
An alternative would be to devote the manned resources to not grow
minute
dependencies on large stacks. (That ship has probably sailed in terms of
firefox-in-the-distro, (...)

Unless Firefox has changed since the last time I touched the codebase, I'm
pretty sure that it has all the Rust crates vendored which it needs. So,
Firefox alone shouldn't be a problem.

I think Rust projects will always tend to vendoring, because the huge
micro-dependency style system that exists means we'll never keep up trying
to package these.

For tarballs that comes from upstream can be the case, but I am not sure that
this ideal for openSUSE.

Kanidm has ~200 crate indirect dependencies on it's own,
I can't imagine how many firefox has. It's a waste of our time to try to
package all 200 when we could be putting that time into other things
instead.

You already pointed a reason of why doing this effort makes sense: security
updates.

We have a full build system designed to track the dependencies, and build the
required subset automatically. Throwing that out of the window for a new
language is IMO wrong.

We do traditionally vendoring in Java, but an heroic effort of one developer
is changing this, reusing solutions from Fedora, RedHat or Debian, and a lot
of smart work.


A small aside here, I'd like to see some more collaboration between
Fedora and SUSE on the Java stuff. We just don't have enough people
working on this, and there are islands of heroes that could be sharing
efforts instead of doing it over and over...

This essentially means we are always at the whims of those
vendored dependencies and what they require, and that is highly likely to
be the "latest" stable compiler.

I think we should aim to:

* Have rustc/cargo move with the upstream cadence, with automation as
suggested into all SLE/LEAP/TW/Other

+1, I think that this is a good starting point.

Neal, what do you think of the idea from Ludwig of having a system rust
compiler (more stable and conservative, used to build all the openSUSE rings),
and a updated version of the compiler co-installable for developers.


It's not a _terrible_ idea. The only problem with it is that Firefox
forces Rust to move forward anyway. That's why RHEL doesn't do this
right now, either.

* Do not attempt to package crates - only package leaves IE consuming
projects

I do not agree here. The effort of designing scripts to update the crates,
macros that will help, supporting multiple versions of the same crate, etc is
so big compared with `cargo vendor`!

Maybe we can do something similar of what go is doing:

https://en.opensuse.org/openSUSE:Packaging_Go

Maybe using only BuildRequires instead of both Requires and BuildRequires if
this is possible, and designing a similar set of macros here.

Neal, what is the plan in Fedora for this?


In Fedora, we've just completely redone and revitalized Go packaging
in the Fedora Go SIG, based on the strategy done for Fedora Rust.

This was rolled out in Fedora 31:
https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines

And this is codified as new packaging guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/

We also have the go2rpm tool: https://pagure.io/GoSIG/go2rpm

* Improve our rust macros and packaging guides around this topic.

Yes.

We probably should copy the document from Fedora once we've
bootstrapped the crates ecosystem in Tumbleweed.

As much as we want to wring our hands and slow down rust, and do things "our
way" we can't - we have to follow and adapt in this case.

So where do we start to start to achieve this?

You are making very hard questions : ))

I am personally in a phase that I try to have a view of what we want, and what
are the good decisions. Fedora and Debian communities are spending a lot of
thinking here, so before moving I want to have more information.


The assumption here is that Rust needs to be slowed down. That's not
the case at all. You can move fast _without_ breaking things. The
problem is that today there are no Rust compiler and language
developers who understand this and help factor that into the future
development of the stack.



--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups