GNU bug report logs -
#56684
[PATCH 1/3] Bump rust 1.57 -> 1.58
Previous Next
Full log
Message #28 received at 56684 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 (application/pgp-keys, attachment)]
[OpenPGP_signature (application/pgp-signature, attachment)]
This bug report was last modified 2 years and 287 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.