Mailinglist Archive: opensuse-packaging (97 mails)

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


On 25 Nov 2019, at 19:45, Richard Biener <rguenther@xxxxxxx> wrote:

On Fri, 22 Nov 2019, William Brown wrote:



On 22 Nov 2019, at 03:04, Alberto Planas Dominguez <aplanas@xxxxxxx> wrote:

On Thursday, November 21, 2019 8:40:19 AM CET Richard Biener wrote:

[cut a lot here]

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

What is wrong on the idea of having two compilers: the system one used for
the
distribution, and the one that can be updated and expected to be used by
developers.

Another idea is to have one single compiler, the system-wide one, and
provide
a rustup binary that the developer can use to install rust and cargo on the
users $HOME. Dany Marcoux already submitted the package, but later was
closed.

I personally prefer the 2 compiler idea, tho, but this is irrelevant.

The 2 compiler idea is kind of a problem? I have a version on my machine
that I was developing with (1.39.0), and encountered version (1.36.0) on
leap which didn't have a feature I required.

Of course this happens with C++ language features evolving as well.
And we _do_ have multiple(!) GCC C++ compilers around, also specifically
to address this problem. So I see no problem with having multiple
rust compilers around.

It's not the presence of multiple compilers thats a problem, it's the rules
around them.

C really hasn't changed much - new gcc versions fix bugs or work faster etc.
It's not a big deal.

Rust compiler versions introduce large, changing feature sets, that really
affect the usage of the language. This year alone I think maybeuninit,
async/await, try_from all come to mind. The issue is that what we ask
developers to use (latest and greatest, all upstream deps) is in conflict when
we go to package those software into suse which will use a "stable" compiler
(older version, ie missing features) because those upstream dependencies will
latch onto those new features very quickly. There are already upstream crates
that won't compile with a 6 month old compiler - let alone 1 year or more.

I think my point is that I want the path from developer to packager and
maintainer to be simpler and laid out, and our ecosystem supporting that
instead of throwing up barriers or hurdles.

It's also worth bearing in mind that rust does not have most of the issues
which makes C developers so anxious or conservative around versioning and
releases. As mentioned, rust is closer as an experience to docker than C.



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