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

Previous Next

Full log

Message #35 received at 30831 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Nikolai Merinov <nikolai.merinov <at> member.fsf.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>,
 Danny Milosavljevic <dannym <at> scratchpost.org>, 30831 <at> debbugs.gnu.org
Subject: Re: [bug#30831] [PATCH] gnu: rust: Update rust from 1.22.1 release to
 1.24.1
Date: Tue, 27 Mar 2018 09:41:05 +0200

Hello Nikolai,

Nikolai Merinov <nikolai.merinov <at> member.fsf.org> skribis:

> Ricardo Wurmus <rekado <at> elephly.net> writes:
>
>> Ludovic Courtès <ludo <at> gnu.org> writes:
>>
>>> Hello,
>>>
>>> Nikolai Merinov <nikolai.merinov <at> member.fsf.org> skribis:
>>>
>>>> Actually there is two ways to achieve this:
>>>> 1. Constantly update bootsrap binaries version.
>>>> 2. For each new release create new package. As result we'll be able to
>>>> use old rust release to build each new rust release. E.g. we can use
>>>> 1.21.0 bootstrap binaries, then build 1.22.0 rust and use it to build
>>>> 1.23.0 rust and then use it to build 1.24.1 rust.
>>>>
>>>> Which way is preferable? 
>>>
>>> Like I wrote, I would prefer option #2, so as to increase “binary
>>> diversity” and not rely on builds made by upstream.
>>>
>>> This obviously relates to <http://bootstrappable.org/>.  Ricardo, what’s
>>> your take on this?
>>
>> I agree.  In the long run, however, I’d prefer for Rust to be
>> bootstrapped through one of the alternative implementations.  Then we
>> don’t need to keep a long chain of older versions.
>>
>> Currently, however, I don’t see a way around it.
>
> Hi, I prepared proof-of-concept solution with rust-bootstrap frozed on
> 1.22.1 release.

Would it be an option to stick to 1.21?  Or is it already too difficult?
(Apologies if this was already answered previously.)  I’m asking because
I wonder how big the temptation will be to upgrade ‘rust-bootstrap’
again next time.

> Do you think suggested code with "split all code to small steps and
> remove fixed issues in new releases" is correct way to provide series
> of releases? Or it will be better to copy builder code to state it
> directly that this specific modification is tested on each rust
> release?

I’m not sure what you mean.

Danny, you probably have more experience than I do with Rust.  :-)
Thoughts?

Thanks,
Ludo’.

Previous Next

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