unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: 22990@debbugs.gnu.org
Subject: bug#22990: Grafts leads to inefficient substitute info retrieval
Date: Wed, 11 Jan 2017 10:54:42 +0100	[thread overview]
Message-ID: <874m15yl99.fsf@gnu.org> (raw)
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")

ludo@gnu.org (Ludovic Courtès) skribis:

> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> ludo@gnu.org (Ludovic Courtès) skribis:
>
> [...]
>
>>> To achieve this, I’m thinking of extending gexp code such that gexp
>>> compilers can return a list of applicable grafts.  The ‘package’
>>> compiler would do #:graft? #f and instead let ‘gexp->derivation’ call
>>> ‘graft-derivation’.
>>
>> The ‘wip-gexp-grafts’ branch does that.  Namely, it’s 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’d first build the profile as is, and only then
>> would we graft it.
>>
>> Right now the tip of this branch is a hack such that ‘guix package’:
>>
>>   1. Builds the original (ungrafted) derivation of the profile;
>>
>>   2. Manually calls ‘graft-derivation’ on that, passing it the list of
>>      applicable grafts.
>>
>> Conceptually it’s what we want to do, but the drawback is that the
>> caller (here ‘guix package’) 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 “build continuation”: a derivation can
> be annotated with a continuation, and the ‘build-things’ procedure will
> loop over continuations and return the final results (that only works
> for derivations directly passed as an argument to ‘build-things’.)

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’t fly.
It works well for things like a profile or the system derivation, but
breaks for less trivial things.

For example, if you’re 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’t have the desired effect.

I’ve pushed ‘wip-gexp-grafts’ again but it seems to be a dead end.

Ludo’.

  reply	other threads:[~2017-01-11  9:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11 16:52 bug#22990: Grafts leads to inefficient substitute info retrieval Ludovic Courtès
2016-03-12  9:23 ` Alex Kost
2016-03-13 12:11   ` Ludovic Courtès
2016-03-15 18:49     ` Mark H Weaver
2016-03-15 21:50       ` Ludovic Courtès
2016-03-15  8:24 ` Ludovic Courtès
2017-01-08 21:44 ` Ludovic Courtès
2017-01-09 22:55   ` Ludovic Courtès
2017-01-11  9:54     ` Ludovic Courtès [this message]
2017-01-11 10:51       ` David Craven
2017-01-11 21:19         ` Ludovic Courtès
2020-03-29 13:41 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874m15yl99.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=22990@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).