Re: Expensive builds when computing channel instance derivations

[Ludovic Courtès]

Hi,

Christopher Baines <mail@cbaines.net> skribis:

> I think I figured out that it's related to grafts. I've attached a test
> script which computes the channel instance derivation for mips64el-linux
> which I'm not set up to build things for (if you can build for
> mips64el-linux, replace this with a system you can't build for). You'll
> need to use the attached patch (also present on [2]) when running this
> script.
>
> 2: 
> https://git.cbaines.net/guix/log/?h=channel-instances-manifest-graft-control
>
> When I run this script locally, it first succeeds in computing the
> channel instance derivation when grafts are disabled, but then fails
> when grafts are enabled:
>
>   while setting up the build environment: a `mips64el-linux' is required
>   to build
>   `/gnu/store/g40shyhsd00r5dq3mm76c2b1krnr1njh-guile-bootstrap-2.0.drv',
>   but I am a `x86_64-linux'
>
> Even though I think this shows that grafts are involved, I'm not sure
> what this means? I'm guessing that the effects of grafts aren't as clear
> cut as for packages here, since the grafts are happening here as part of
> computing a derivation I'm guessing that the derivation is actually
> built with the grafted outputs, which differs from how grafts affect
> packages. Given this, I guess computing the derivation without grafts
> means that the replacements that would be grafted in are just not used
> at all.
>
> To recap on my aim here, I really just want to be able to compute
> channel instance derivations without performing any expensive builds, or
> if that's not possible, it would be good to understand why?

In general, computing the derivation of a package may incur
builds/downloads due to the way grafts work: depending on the *build
result* of a package, ‘package->derivation’ might return a grafting
derivation or it might return the original derivation.

The “Computing Guix derivation” bit of ‘guix pull’ is no exception: it
computes the derivation of objects that depend on packages that may need
to be grafted.  Thus, it ends up triggering builds as part of this
process.

It would be tempting to turn off grafts in this case.  But then, ‘guix
pull’ would always give us an ungrafted Guix, which is undesirable.  For
the purposes of the Data Service though, you could consider turning off
grafts globally.

HTH!

Ludo’.