From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Sassmannshausen Subject: Re: [PATCH] doc: Mention "guix pull" during installation. Date: Mon, 19 Dec 2016 08:41:24 +0100 Message-ID: <87oa08l61n.fsf@gmail.com> References: <82b3233597949c866c26628054117ee3@mykolab.ch> <20161217173856.GA30440@jasmine> <87inqho626.fsf@gnu.org> Reply-To: alex.sassmannshausen@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIsZg-0006I5-Ig for guix-devel@gnu.org; Mon, 19 Dec 2016 02:41:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIsZd-0001Xp-Eg for guix-devel@gnu.org; Mon, 19 Dec 2016 02:41:32 -0500 In-reply-to: <87inqho626.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org, Petter Ludovic Courtès writes: > Hello! > > Leo Famulari skribis: > >> I've recently gave an explanation of why I think using `guix pull` >> before installing GuixSD should not be recommended unconditionally: >> >> http://lists.gnu.org/archive/html/bug-guix/2016-11/msg00047.html >> >> In the specific case of installing GuixSD 0.11.0 today, `guix pull` is >> necessary, because we lack the substitutes, and some packages can't be >> built at all now [1]. But, adding these lines to the manual now won't >> make it show up in the 0.11.0 installer manual. >> >> I think we should work on improving our infrastructure in the next >> release cycle, and revisit this change to the manual if we are still >> having problems before the 0.13.0 release. >> >> What does everyone think? > > I agree with everything you wrote here. > > Ludo’. I think I too agree here. Especially as my experience (running GuixSD on i686 bare metal) suggests that `guix pull` can actually result in packages that do not quite build reliably. There currently seems to be a `guix pull` sweet spot when the substitutes are not too old yet the recipes not too new… I think the best solution would definitely be guaranteed availability of substitutes for releases until at least the next release — so I greatly appreciate the work that is being done to on the infrastructure side. My 2¢, Alex