l...@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’.
