From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: Re: successful installation, but problems updating Date: Sat, 11 Nov 2017 13:06:23 -0500 Message-ID: <86zi7spu5c.fsf@gmail.com> References: <20171106091656.6e775deb@graviton.instanton> <20171106111829.1e07b138@hitpoints.browniehive.net> <87fu9mptdl.fsf@gmail.com> <20171110162818.GA11031@jasmine.lan> <8760ahpv8x.fsf@gmail.com> <86bmk8rfz9.fsf@gmail.com> <878tfcbv9k.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50868) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDaAp-0008EJ-9z for help-guix@gnu.org; Sat, 11 Nov 2017 13:06:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDaAl-0006oP-To for help-guix@gnu.org; Sat, 11 Nov 2017 13:06:31 -0500 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:35912) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eDaAl-0006nt-Mz for help-guix@gnu.org; Sat, 11 Nov 2017 13:06:27 -0500 Received: by mail-wm0-x22d.google.com with SMTP id r68so8052299wmr.1 for ; Sat, 11 Nov 2017 10:06:27 -0800 (PST) In-Reply-To: <878tfcbv9k.fsf@gmail.com> (Chris Marusich's message of "Sat, 11 Nov 2017 09:05:59 -0800") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Chris Marusich Cc: "help-guix@gnu.org" On 11/11/2017 at 09:05 Chris Marusich writes: > myglc2 writes: > >> On 11/10/2017 at 15:30 Chris Marusich writes: >> >>> Hi Leo, >>> >>> Leo Famulari writes: >>> >>>> Substition is considered to fail when Guix is expecting a substitute but >>>> the server returns 404, 504, or some other unexpected problem occurs. It >>>> is not considered to fail if the server initially reports that no >>>> substitute is available. >> >> Hi Leo, this is a wonderful clarification of behavior that has confused >> me for 1.5 years! >>> >>> Thank you for the clarification. This is what I did not understand. I >>> read the manual and got the impression that when --fallback has not been >>> given, if a given substitute cannot be found (regardless of whether or >>> not a substitute server claimed to provide one), then Guix will not >>> build it. I see now that my understanding was mistaken. >> >> I had this mistaken impression too. >>> >>> I've attached a patch which tries to clarify this in the manual. What >>> do you think of it? >> >> Hey Chris, >> >> How about saying what Leo said right up front in the substitutes >> section. This allows the --fallback addition to be more brief. >> >> Rough draft below. >> >> WDYT? - George >> >> 1 file changed, 9 insertions(+), 2 deletions(-) >> doc/guix.texi | 11 +++++++++-- >> >> modified doc/guix.texi >> @@ -2120,6 +2120,13 @@ server. We call these pre-built items @dfn{substitutes}---they are >> substitutes for local build results. In many cases, downloading a >> substitute is much faster than building things locally. >> >> +When substitutes are enabled (the default) and a substitute is not >> +available the build will take place locally. If a substitute is >> +available but substitution fails, e.g., the substitute server returns >> +404, 504, times out, or some other unexpected problem occurs, guix stops >> +and reports an error unless --fallback or --keep-going options are >> +specified. >> + >> Substitutes can be anything resulting from a derivation build >> (@pxref{Derivations}). Of course, in the common case, they are >> pre-built package binaries, but source tarballs, for instance, which >> @@ -5192,8 +5199,8 @@ derivations has failed. >> Do not build the derivations. >> >> @item --fallback >> -When substituting a pre-built binary fails, fall back to building >> -packages locally. >> +Attempt to build locally instead of issuing an error when substitutes >> +are enabled and the substitution of a pre-built binary fails. >> >> @item --substitute-urls=@var{urls} >> @anchor{client-substitute-urls} > > I think I like the way you wrote it better. I'm fine with that. I was > hoping not to add to the already-voluminous paragraphs about Substitutes > at the top of section 3.3, but honestly as long as this info is in the > manual, I'm happy. I agree w/you Substitutes is overwhelming ;-) Meanwhile, so will you submit the patch, or do you want me to? TIA - George