Hi Ludovic,

In attachement you can find updated patch with rust-bootstrap 1.22.1 and
rust packages of 1.23.0 and 1.24.1 releases. I made small changes like
replacement (zero? (system* ...)) with (invoke ...) and checked
reproducability.

Please find my comments below.

Regards,
Nikolai

ludo@gnu.org (Ludovic Courtès) writes:

> Hello Nikolai,
>
> Nikolai Merinov <nikolai.merinov@member.fsf.org> skribis:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> Hello,
>>>>
>>>> Nikolai Merinov <nikolai.merinov@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.
>

It should be easy enough to stick with 1.21 bootstrap (still we already
have package for 1.22), but:
1. We still should change code for bootstrap package to match design
where "rustc" and "cargo" installed from one package.
2. Rust 1.23 and 1.24 can use same "config.toml", while rust 1.22 have
different "config.toml". I do not know how to make it to look pretty in
first time. For additional information look below about package code
design.
3. My machine is pretty slow and testing reproducablity for three
versions in a row will take two days :-)


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

I talking about how to write code for packages. e.g. if we have:

  (package
    (name "rust")
    (version "1.23.0")
    ...
    (arguments
      ...
       #:phases (modify-phases %standard-phases
                  ...
                  (add-after ... 'disable-test-1)
                  (add-after ... 'disable-test-2)
                  (add-after ... 'fix-source-bug-1)
                  (add-after ... 'fix-source-bug-2)
                  (add-after ... 'fix-source-bug-3)
                  (replace 'configure ...)
                  (replace 'check ...)
                  ...)))

Then how should look package for 1.24 release?

It can be inherited from previous one and replace some of old steps

  (let ((base-rust rust-1.23))
    (package
      (inherit base-rust)
      (version "1.24.1")
      ...
      (native-inputs
       (alist-replace "cargo-bootstrap" (list base-rust "cargo")
                      (alist-replace "rustc-bootstrap" (list base-rust)
                                     (package-native-inputs base-rust))))
      (arguments (substitute-keyword-arguments (package-arguments base-rust)
                   ((#:phases phases)
                    `(modify-phases ,phases
                       (delete 'fix-source-bug-1)
                       (add-after ... 'disable-test-3)
                       (replace 'fix-source-bug-2
                         (lambda* ....))))))))

Or we should copy all steps required for each new release:

  (package
    (name "rust")
    (version "1.24.0")
    ...
    (arguments
      ...
       #:phases (modify-phases %standard-phases
                  ...
                  (add-after ... 'disable-test-1)
                  (add-after ... 'disable-test-2)
                  (add-after ... 'disable-test-3)
                  (add-after ... 'fix-source-bug-1)
                  (add-after ... 'fix-source-bug-3)
                  (replace 'configure ...)
                  (replace 'check ...)
                  ...)))

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.

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