From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#31210: Perl graft breakage Date: Thu, 19 Apr 2018 06:28:06 -0400 Message-ID: <87d0yvo5hl.fsf@netris.org> References: <20180415153405.5973-1-mbakke@fastmail.com> <20180418180850.GA11245@jasmine.lan> <87muy0iaxm.fsf@netris.org> <20180418205236.GA26365@jasmine.lan> <87h8o7oevo.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f96pJ-0007K1-9O for bug-guix@gnu.org; Thu, 19 Apr 2018 06:30:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f96pG-00079w-3A for bug-guix@gnu.org; Thu, 19 Apr 2018 06:30:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:52242) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f96pG-00079f-0G for bug-guix@gnu.org; Thu, 19 Apr 2018 06:30:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f96pF-0000cT-Q0 for bug-guix@gnu.org; Thu, 19 Apr 2018 06:30:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87h8o7oevo.fsf@netris.org> (Mark H. Weaver's message of "Thu, 19 Apr 2018 03:05:15 -0400") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Leo Famulari Cc: 31210@debbugs.gnu.org Hi again, I wrote: > The problem is that you should never use 'package/inherit' to create a > graft. That leads to an infinite tower of grafts. I should explain why this is. We cannot use (package/inherit P ...) to define the replacement of package P, because it leads to a circular definition. Recall that (package/inherit P ...) applies the given transformation to both P and its replacement. In this case, P's replacement is the thing we're trying to define. See the circularity? This would lead to an infinite recursion if not for the fact that 'replacement' is a "thunked" field, i.e. its evaluation is delayed. Instead it leads to an infinite series of replacements, each one based on the previous one, but with the transformation applied one more time. In this example with 'perl', the transformation involved adding a new phase. Let's call that transformation 'f', so that (f perl) is the replacement you wanted. Since you used (package/inherit perl ...) to define perl's replacement, it led to an infinite series of replacements: perl (f perl) (f (f perl)) (f (f (f perl))) ... I would have expected the grafting machinery to iterate until reaching the end of this series of replacements. I guess it didn't because the (f (f perl)) build failed, since it added the phase twice. Also note that since 'package/inherit' implicitly adds its own 'replacement' field, if you manually override 'replacement' within 'package/inherit' as you did in your first proposed patch, it expands into a package definition with two 'replacement' overrides, like this: (package (inherit P) (replacement #f) ... (replacement ...)) Ideally, guix records would report an error in this case. Regards, Mark