Mailinglist Archive: opensuse-packaging (97 mails)

< Previous Next >
Re: [opensuse-packaging] On how to improve Rust packaging experience for suse
On Wed, 20 Nov 2019, Neal Gompa wrote:

On Wed, Nov 20, 2019 at 6:26 PM William Brown <wbrown@xxxxxxx> wrote:

So the more I'm reading into this thread the more I think that my
conclusion here is:

* We should have rust/cargo's release cadence seperate from the release
cycles of a
distro (ie fedora modularity in a way, or tw style)
* Packaging crates to rpms is not feasible or scalable, and we should
not attempt it
- cargo already has vendor and all the packages I've seen in obs today
use vendored dependencies.
* We should instead focus on packaging "edge" programs that use rust IE
firefox, ripgrep.
* Focus pkg QA efforts on the edge packages
* We could consider integration of tools like cargo-audit to scan for
security issues in
packages (similar to clamav in obs already) to help ensure vendored
deps are "up to date".
* Improve the rpm spec docs related to rust/cargo to help make it easier
for people to
give us packaged programs.

It could also happen that certain software projects like librsvg or
389-ds are being
forked in their last non-Rust version to avoid the bootstrap issues. It's
not that
projects haven't been forked in the past over such fundamental project
philosophy issues
(XFree86/X.Org, libav/ffmpeg, OpenOffice/LibreOffice, eglibc/glibc,
ecgs/gcc etc).

I don't think the hammer method that some projects are currently using to
push Rust
is going to be successful in the long-term.

As the person who is adding rust to 389-ds, the maintainer of it at suse,
and part of the upstream team (the rh people are also on board with this),
I don't think I'll be forking "the last non-rust version" as that would be
a bit self defeating ...

We need productive solutions, not complaining that rust is different to
"how it's always been".

Alright, I'm going to come out and say it. You need to pull that stick
out of your rear.

What gives you the right to be so arrogant as to think that you're
better than everyone else who has been talking in this thread, and the
5+ people working on the Rust ecosystem across *three* distributions?

We already update the Rust compiler stack as fast as we can, and quite
frankly, you should be *happy* we do this with basically no
involvement from you, the *only* person I know of at SUSE doing *any*
meaningful Rust development work. Moreover, you are *paid* to consider
SLE and openSUSE Leap (and to a lesser extent RHEL and CentOS) as
targets for your code work. That means *you* must work with the
restrictions you have. Cargo is perfectly capable of giving you
dependencies that work for your version of the Rust compiler. I've
done Rust development work, you *don't* need the latest Rust compiler
all the time. You are not developing anything that needs it. Your
dependencies are no excuse, as you can control those and use versions
that work with your Rust language compiler that you have available.

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

At this point, you just want permission to do something that's clearly
not allowed in openSUSE policy.

Now I didn't follow the thread too closely so I don't remember what
the issue is. I believe policy is made by the openSUSE developers
so there is (and should!) be flexibility here.

Well, I'm not going to give you that
blessing. I know we have a whole bunch of people violating the rules
with various ecosystems (Java, Go, Rust [for now], etc.). That does
not make it okay. That just means the openSUSE review team doesn't
care enough to block them right now. There is no rules that expressly
permit this, so guess what? That means someone could decide to care
and rip all those packages out.

Stop being rude and start being constructive.

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.


Richard Biener <rguenther@xxxxxxx>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
< Previous Next >