[bug#56684] [PATCH 1/3] Bump rust 1.57 -> 1.58

[Maxime Devos]

On 22-07-2022 03:33, Jim Newsome wrote:

> Trying to compile a release with an older compiler than it was 
> originally compiled with seems unlikely to go well. 

It usually works fine for GCC. For Rust, it's a bit less likely given 
the rate at which APIs etc are added, but it's possible that once in a 
while a version can be skipped. Yes, the upstream docs say that X+1 is 
compiled with X, but this is Guix not upstream and upstream doesn't seem 
to care about bootstrapping much, I do not recommend just following the 
method from the docs as a rule or even a recommendation.

(Basically the is-ought problem in another context.)

> It's not explicitly stated that it *won't* work, but it seems unlikely 
> that it would, and would take a lot of time to verify by trial and error. 

? All you need to do is, say, remove 1.58 and bootstrap 1.59 directly 
from 1.57 and see if that compiles and then also give current version in 
guix -> 1.59 a try, etc, if not try 1.57 -> 1.59..

I don't see much trial and error here, there are only a few possible 
combinations.

Yes, it will take some time to compile (rust is big), but this only 
needs to be done once (or zero, the previous patch submitter tried out 
some combinations, those don't have to be done again) and all the 
potential compilation time savings will be shared to everyone, and while 
it is compiling you can still do other things.

If it's too much for your computer if that's what you mean, I suppose it 
would be possible to set up a branch that tries out various combinations 
at ci.guix.gnu.org (it has lots of x86-64 machines).

> Oops! It looks like that is both a bit further along and more 
> ambitious than my version. It's also been lingering for a while, while 
> guix's version of Rust falls further behind, making me wonder if it's 
> worth trying to move things up with something closer to my naive 
> approach in the meantime. 
If you mean ignoring the already existing patch and making a new one 
that does less, this does not incline me to review your patch and 
probably would be frustrating to the original patch submitter, causing 
your patch to linger too.  What I meant is: if possible, go for the 
_original_ patch, improve it with parts of _your_ patch (taking the best 
of both) and submit that as a v2 or such, otherwise just go for the 
original patch and review or test it (e.g., verify it compiles 
reproducibly and share the hash (with "guix hash 
/gnu/store/the-store-item", not the hash in /gnu/store/HASH-...)).

Summarised: double-work tends to cause more lingering, not less.

Greetings,
Maxime.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature