GNU bug report logs - #30831
[PATCH] gnu: rust: Update rust from 1.22.1 release to 1.24.1

Previous Next

Full log

View this message in rfc822 format

From: Marius Bakke <mbakke <at> fastmail.com>
To: Danny Milosavljevic <dannym <at> scratchpost.org>, Nikolai Merinov <nikolai.merinov <at> member.fsf.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 30831 <at> debbugs.gnu.org
Subject: [bug#30831] [PATCH] gnu: rust: Update rust from 1.22.1 release to 1.24.1
Date: Tue, 27 Mar 2018 20:08:01 +0200

[Message part 1 (text/plain, inline)]

Danny Milosavljevic <dannym <at> scratchpost.org> writes:

> Hi Nikolai,
>
> I think the incremental (first) version is the best one since you can see
> which bugs are worked around by us and which are fixed per release at a glance.
>
> But really it doesn't matter much which.
>
>> Second solution looks too verbose for me, but with first solution on
>> long chain of versions it will be very hard to manage which changes we
>> have in newest package.
>
> I hope we won't have a long chain of cumulative Rust versions in Guix.  I know
> that Rust upstream likes to do this chain of Rust1 -> Rust2 -> Rust3 -> Rust4
> but that's not really scalable - especially since even one Rust takes a day
> to compile.  We should try to get mrust [1] to work and use it to compile just
> the newest Rust.  If it doesn't work we can still fall back to one of the
> other ways later.
>
> (What Mozilla recommends is we compile Rust1, use Rust2 to compile Rust3, use
> Rust3 to compile Rust4, likewise for each new release)

I think we should heed upstreams advice in that case.  A long bootstrap
chain is really only a problem during 'core-updates', no?

IIUC mrustc only targets x86_64 currently, so I don't expect it to
become viable for Guix in a good while.

> [1] https://github.com/thepowersgang/mrustc

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.