From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#22990: Grafts leads to inefficient substitute info retrieval Date: Wed, 11 Jan 2017 10:54:42 +0100 Message-ID: <874m15yl99.fsf@gnu.org> References: <8737rxx8gk.fsf@gnu.org> <87k2a5rzue.fsf@gnu.org> <877f633kt1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cRFcY-0000Qf-A9 for bug-guix@gnu.org; Wed, 11 Jan 2017 04:55:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cRFcU-0003dA-AX for bug-guix@gnu.org; Wed, 11 Jan 2017 04:55:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:33992) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cRFcU-0003cJ-44 for bug-guix@gnu.org; Wed, 11 Jan 2017 04:55:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cRFcT-0001Of-Qp for bug-guix@gnu.org; Wed, 11 Jan 2017 04:55:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <877f633kt1.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 09 Jan 2017 23:55:38 +0100") 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: 22990@debbugs.gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) skribis: > >> ludo@gnu.org (Ludovic Court=C3=A8s) skribis: > > [...] > >>> To achieve this, I=E2=80=99m thinking of extending gexp code such that = gexp >>> compilers can return a list of applicable grafts. The =E2=80=98package= =E2=80=99 >>> compiler would do #:graft? #f and instead let =E2=80=98gexp->derivation= =E2=80=99 call >>> =E2=80=98graft-derivation=E2=80=99. >> >> The =E2=80=98wip-gexp-grafts=E2=80=99 branch does that. Namely, it=E2= =80=99s possible to know >> what grafts would apply to a gexp derivation build, so that one can >> first build ungrafted, and then apply the grafts to the results. >> So for a profile, we=E2=80=99d first build the profile as is, and only t= hen >> would we graft it. >> >> Right now the tip of this branch is a hack such that =E2=80=98guix packa= ge=E2=80=99: >> >> 1. Builds the original (ungrafted) derivation of the profile; >> >> 2. Manually calls =E2=80=98graft-derivation=E2=80=99 on that, passing = it the list of >> applicable grafts. >> >> Conceptually it=E2=80=99s what we want to do, but the drawback is that t= he >> caller (here =E2=80=98guix package=E2=80=99) goes through a lot of hops = to get the list >> of grafts and to apply it. >> >> I think we should instead have a way to annotate a derivation with a >> list of grafts, as well as a procedure to build that derivations in two >> phases (first the original derivation, then the grafts). > > The current iteration introduces =E2=80=9Cbuild continuation=E2=80=9D: a = derivation can > be annotated with a continuation, and the =E2=80=98build-things=E2=80=99 = procedure will > loop over continuations and return the final results (that only works > for derivations directly passed as an argument to =E2=80=98build-things= =E2=80=99.) On second thought, the whole idea of applying grafts on the final result (instead of applying grafts at each step like we do now) doesn=E2=80=99t fl= y. It works well for things like a profile or the system derivation, but breaks for less trivial things. For example, if you=E2=80=99re building a VM image or a binary tarball, you really need to graft packages early on; trying to graft the VM image or binary tarball wouldn=E2=80=99t have the desired effect. I=E2=80=99ve pushed =E2=80=98wip-gexp-grafts=E2=80=99 again but it seems to= be a dead end. Ludo=E2=80=99.