GNU bug report logs - #22990
Grafts leads to inefficient substitute info retrieval

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: 22990 <at> debbugs.gnu.org
Subject: bug#22990: Grafts leads to inefficient substitute info retrieval
Date: Sun, 08 Jan 2017 22:44:41 +0100

ludo <at> gnu.org (Ludovic Courtès) skribis:

> Concretely, what this means is this:
>
>   $ guix package -u
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 100.0%
>   […]
>   The following files would be downloaded:
>
> Each of the initial “updating list” message corresponds to an HTTP
> request for a single narinfo file, which can take around 1 second.
>
> Instead, the ideal thing would be to fetch the narinfo files for all the
> relevant packages at once; that way, we’d spawn ‘guix substitute’ only
> once, and it would benefit from HTTP pipelining (one round-trip instead
> of N.)
>
> 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).

To be continued…

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.