Mailinglist Archive: opensuse-packaging (94 mails)

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

On Wed, 20 Nov 2019, William Brown wrote:

The crate system will never stabilise - that's the issue - you have
hundreds of crates vying to get the latest compiler features, and
projects that depend on them, and will set their versions accordingly.
And because / rust has no concept of a security update vs
feature update, we'll have to update all the time.

If we try to package crates, we'll be forever in a mountain of continual
reviews and packaging.

But if we just focus on leaf packages which have vendored deps and the
compiler, that's much more manageable.

We have to focus on value for our time - is it worth our time to be
doing the crates? Or the projects that people use?

A good point indeed.

I think it's worth really highlighting *rust is not C*. We can not take
our traditional package ideals and apply it to rust else we'll fail. We
need to think about this differently. That's my point here. If we can't
even keep the compiler up to date with what projects need, how are we
going to maintain hundreds of crate versions?

I see only some ways for the enterprise (or other more stable) distros,
and all are terrible:
a) bundle rustc itself (not just the other deps) with the packages
requiring it. I hear that's what they call "vendoring".
b) continously update the one and only rustc compiler in distros (also
the enterprise ones). Supposedly rust is backward compatible, so that
should continue to be able to compile older sources like librsvg which
we might not want to contiously update in the enterprise distros. I
would not trust this claim from a community that happily changes
language and standard library every six weeks, I don't think they have
a mental model of what stability really means.
c) provide two rustc compilers in parallel, one remaining stable for
building the packages we don't (continously) update and another that
quickly updates.

Whatever we choose (the only realistic option seems (c) to me), we should
make fairly sure that we do _not_ encode any requirements on Rust into
base components of our system (librsvg comes to mind, and it is a huge
problem that parts are written in Rust; it's a basic component and
hinders the Risc-V distro, we have to keep using an old version of
libsvg there). It's simply not a good decision to base system components
on a quickly changing eco system.

In that vain I doubt your choice of using Rust in 389-ds is a very good
one; please think hard about the consequences for distros that want to be
maintained the next 20 years. You are right that we can't make that
choice for other people wanting to use the next fancy language (though we
sometimes can in not using what they produce), but you can make that
choice for yourself and have to balance the wish for nice language
features against the downsides of that eco system.

(I personally think requiring an eco system that's only N<4 years old, and
is _known_ to change extremely fast, for system components (in comparison
to hobby projects or only using it optionally), is actually more than a
mere bad choice, it's bordering on irresponsible software design)


LCP [Stasiek]

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 >