From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0t1u-0002gS-Rq for guix-patches@gnu.org; Tue, 27 Mar 2018 14:09:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f0t1q-0008WS-Ve for guix-patches@gnu.org; Tue, 27 Mar 2018 14:09:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:48313) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f0t1q-0008WH-Mk for guix-patches@gnu.org; Tue, 27 Mar 2018 14:09:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f0t1q-0006Xx-86 for guix-patches@gnu.org; Tue, 27 Mar 2018 14:09:02 -0400 Subject: [bug#30831] [PATCH] gnu: rust: Update rust from 1.22.1 release to 1.24.1 Resent-Message-ID: From: Marius Bakke In-Reply-To: <20180327151942.1458e82c@scratchpost.org> References: <874llhdocu.fsf@member.fsf.org> <87bmfmmm78.fsf@gnu.org> <87h8pcckv4.fsf@member.fsf.org> <87efkgvxt1.fsf@gnu.org> <87o9jjc8xg.fsf@elephly.net> <87y3ij25bf.fsf@member.fsf.org> <87in9iynhq.fsf@gnu.org> <87zi2the25.fsf@member.fsf.org> <20180327151942.1458e82c@scratchpost.org> Date: Tue, 27 Mar 2018 20:08:01 +0200 Message-ID: <87h8p1gzni.fsf@fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Danny Milosavljevic , Nikolai Merinov Cc: Ricardo Wurmus , 30831@debbugs.gnu.org --=-=-= Content-Type: text/plain Danny Milosavljevic 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlq6iIEACgkQoqBt8qM6 VPoutggAsBdPlVz5Dhu03PmZapdPp/qjLP7WAn2pf96OgcKJrxCZC+u605mNjM6j aIO2sp/nY5rtlmcHxCrYuLyDNVdRg4zlrmbOedsnMX+IGLfTSzG5oNhAR9o2xVhc 3HSekMrbrzF0X9LRQelwz/2AnEQuITzn7zb1xqEZLaa/RksyovEBiGvz64yoRn+p Fwf8maAf5Ukcbo98RcfDhY/6rB3Qbxar2DISSwcTIiEfT9RNlbR6Sq13bi09li3N SQIB5IWkUI382+Q4SLa2UauvhxOfIMKOSHBcLjg6FMeL8el2+X5vihPwODyf9uEV 2KEGHGFHBsrbTFo2YBF4CtVvr88C5A== =YLqZ -----END PGP SIGNATURE----- --=-=-=--