bug#61841: ‘guix shell’ computes different package derivation than ‘guix build’

bug#61841: ‘guix shell’ computes different package derivation than ‘guix build’

[Ludovic Courtès]

Look at this weird phenomenon.

First, with ‘guix build’, everything works as expected:

--8<---------------cut here---------------start------------->8---
$ guix describe
Generation 247  Feb 27 2023 08:47:41    (current)
  guix 17bd024
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 17bd0243310754045cdc6cc362c804db4a8f9317
$ guix build ungoo
ungoogled-chromium          ungoogled-chromium-wayland  
$ guix build ungoogled-chromium -n
The following grafts would be made:
   /gnu/store/sb9bva92ycw40jiwvklvdwpr5pqs5y14-ungoogled-chromium-109.0.5414.119-1.drv
   /gnu/store/88bvz2ch3wsiz66qcmhhpbz2i60ms14j-harfbuzz-5.3.1.drv
   /gnu/store/pvrhcbpajl9cf2jjy8p01p5fh6kjf3fi-pipewire-0.3.63.drv
   /gnu/store/mjm6k8l2d0j1j3j3p7rqrrrj2pla4cwa-jack2-1.9.21.drv
$ guix build ungoogled-chromium -n --no-grafts
/gnu/store/p984s3dna89qw3j1s9w1jpz3wjw1jmfg-ungoogled-chromium-109.0.5414.119-1
$ guix build ungoogled-chromium -n --no-grafts -d
/gnu/store/i8f4qri399l1r2k7hrwpdxxgc3q77izw-ungoogled-chromium-109.0.5414.119-1.drv
--8<---------------cut here---------------end--------------->8---

But now ‘guix shell’ (same revision) wants to build ungoogled-chromium:

--8<---------------cut here---------------start------------->8---
$ guix shell ungoogled-chromium -n
The following derivations would be built:
  /gnu/store/6kgc8cd8wn010ba3jnywj2qsjsjk511s-ungoogled-chromium-109.0.5414.119-1.drv
  /gnu/store/xfiqj5qnnld9g8hdh879aa7gp7wprhaf-chromium-109.0.5414.119.tar.xz.drv
  /gnu/store/4ic70ax830gng6fbaqk3mf3rf2x6vf1j-jsoncpp.patch.drv
  /gnu/store/9sbl6km93sgb7wc2b14sc1fgf7alsb79-openjpeg.patch.drv
  /gnu/store/jcx82l35b070dz91aiz6gffgkngcf1gl-zlib.patch.drv

1,930.3 MB would be downloaded
$ guix shell ungoogled-chromium -n --no-grafts
The following derivations would be built:
  /gnu/store/mpfvrssy125chnxsy4qg61kk1a2s235d-profile.drv
  /gnu/store/kyncllwl57l2pk63rc154zdfmbx8759v-ungoogled-chromium-109.0.5414.119-1.drv
  /gnu/store/xfiqj5qnnld9g8hdh879aa7gp7wprhaf-chromium-109.0.5414.119.tar.xz.drv
  /gnu/store/4ic70ax830gng6fbaqk3mf3rf2x6vf1j-jsoncpp.patch.drv
  /gnu/store/9sbl6km93sgb7wc2b14sc1fgf7alsb79-openjpeg.patch.drv
  /gnu/store/jcx82l35b070dz91aiz6gffgkngcf1gl-zlib.patch.drv

1,930.3 MB would be downloaded
--8<---------------cut here---------------end--------------->8---

Why does ‘guix shell’ want to build a different derivation for the same
package?

The derivation ‘guix shell’ computed depends on different *.patch.drv,
compared to the “right” one:

--8<---------------cut here---------------start------------->8---
$ guix gc -R $(guix build ungoogled-chromium -d --no-grafts) |grep -E '(jsoncpp|openjpeg|zlib)\.patch\.drv'
/gnu/store/ysmmqzva7j49x7sswr5kdgdj59dsh8ip-zlib.patch.drv
/gnu/store/iamxhd6d0jqvmjfh458qwhm62bq2adb7-jsoncpp.patch.drv
/gnu/store/03hqmvhl97b8pxrcqahc9xk1bil2pbs3-openjpeg.patch.drv
--8<---------------cut here---------------end--------------->8---

To be continued…

Ludo’.

bug#61841: ‘guix shell’ computes different package derivation than ‘guix build’

[Josselin Poiret via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Look at this weird phenomenon.
>
> First, with ‘guix build’, everything works as expected:
> [...]
> But now ‘guix shell’ (same revision) wants to build ungoogled-chromium:
> [...]
> Why does ‘guix shell’ want to build a different derivation for the same
> package?

Funnily enough, I don't have that problem locally: the `guix shell`
invocation only tells me it's gonna build a profile derivation (I don't
have ungoogled-chromium in my store btw), and the input derivation for
that profile is the same as for `guix build`.

Best,
-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

bug#61841: ‘guix shell’ computes different package derivation than ‘guix build’

[Ludovic Courtès]

Howdy,

Josselin Poiret <dev@jpoiret.xyz> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Look at this weird phenomenon.
>>
>> First, with ‘guix build’, everything works as expected:
>> [...]
>> But now ‘guix shell’ (same revision) wants to build ungoogled-chromium:
>> [...]
>> Why does ‘guix shell’ want to build a different derivation for the same
>> package?
>
> Funnily enough, I don't have that problem locally: the `guix shell`
> invocation only tells me it's gonna build a profile derivation (I don't
> have ungoogled-chromium in my store btw), and the input derivation for
> that profile is the same as for `guix build`.

It was fixed on Monday though, so perhaps you’re using a known-good
revision?

Anyway there are still people complaining about “lack of
ungoogled-chromium substitutes” (most likely: wrong ungoogled-chromium
derivation) right now on IRC.

Ludo’.

bug#61841: ‘guix shell’ computes different package derivation than ‘guix build’

[Josselin Poiret via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> It was fixed on Monday though, so perhaps you’re using a known-good
> revision?

That's probably the piece of info I was missing!  The discussion about
the issue didn't show up in the same thread in my MUA so I thought this
was simply unanswered, my bad.

Best,
-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

[bug#61255] [PATCH 1/5] pack: Extract keyword-ref procedure from debian-archive.

[Maxim Cournoyer]

Rationale: the upcoming rpm-archive builder will also use it.

* guix/scripts/pack.scm:
(keyword-ref): New top-level procedure, extracted from...
(debian-archive): ... here.  Adjust usages accordingly.
---

 guix/scripts/pack.scm | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/guix/scripts/pack.scm b/guix/scripts/pack.scm
index f65642fb85..7e466a2be7 100644
--- a/guix/scripts/pack.scm
+++ b/guix/scripts/pack.scm
@@ -194,6 +194,12 @@ (define (symlink-spec-option-parser opt name arg result)
      (leave (G_ "~a: invalid symlink specification~%")
             arg))))
 
+(define (keyword-ref lst keyword)
+  "Return the value of KEYWORD in LST, else #f."
+  (match (memq keyword lst)
+    ((_ value . _) value)
+    (#f #f)))
+
 \f
 ;;;
 ;;; Tarball format.
@@ -762,20 +768,15 @@ (define data-tarball-file-name (strip-store-file-name
 
             (copy-file #+data-tarball data-tarball-file-name)
 
-            (define (keyword-ref lst keyword)
-              (match (memq keyword lst)
-                ((_ value . _) value)
-                (#f #f)))
-
             ;; Generate the control archive.
             (define control-file
-              (keyword-ref '#$extra-options #:control-file))
+              #$(keyword-ref `(,@extra-options) #:control-file))
 
             (define postinst-file
-              (keyword-ref '#$extra-options #:postinst-file))
+              #$(keyword-ref `(,@extra-options) #:postinst-file))
 
             (define triggers-file
-              (keyword-ref '#$extra-options #:triggers-file))
+              #$(keyword-ref `(,@extra-options) #:triggers-file))
 
             (define control-tarball-file-name
               (string-append "control.tar"
-- 
2.39.1

[bug#61255] [PATCH 2/5] gexp: computed-file: Honor %guile-for-build.

[Maxim Cournoyer]

* guix/gexp.scm (computed-file): Set the default value of the #:guile argument
to that of the %guile-for-build parameter.
---

 guix/gexp.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/guix/gexp.scm b/guix/gexp.scm
index 5f92174a2c..bf75d1f8df 100644
--- a/guix/gexp.scm
+++ b/guix/gexp.scm
@@ -584,7 +584,8 @@ (define-record-type <computed-file>
   (options    computed-file-options))             ;list of arguments
 
 (define* (computed-file name gexp
-                        #:key guile (local-build? #t) (options '()))
+                        #:key (guile (%guile-for-build))
+                        (local-build? #t) (options '()))
   "Return an object representing the store item NAME, a file or directory
 computed by GEXP.  When LOCAL-BUILD? is #t (the default), it ensures the
 corresponding derivation is built locally.  OPTIONS may be used to pass
-- 
2.39.1

[bug#61255] [PATCH 2/5] gexp: computed-file: Honor %guile-for-build.

[Ludovic Courtès]

Hello!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> * guix/gexp.scm (computed-file): Set the default value of the #:guile argument
> to that of the %guile-for-build parameter.

[...]

>  (define* (computed-file name gexp
> -                        #:key guile (local-build? #t) (options '()))
> +                        #:key (guile (%guile-for-build))
> +                        (local-build? #t) (options '()))

I think that would lead ‘computed-file’ to pick (%guile-for-build) at
the wrong time (time of call instead of time of lowering).

Commit ab25eb7caaf5571cc9f8d6397a1eae127d7e29d1 made it #f such that
‘gexp->derivation’ gets to resolve it at the “right” time.

Does that make sense?  But perhaps this approach isn’t suitable in the
use case you’re looking at?

HTH,
Ludo’.

[bug#61255] [PATCH 2/5] gexp: computed-file: Honor %guile-for-build.

[Maxim Cournoyer]

Hi Luvodic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> * guix/gexp.scm (computed-file): Set the default value of the #:guile argument
>> to that of the %guile-for-build parameter.
>
> [...]
>
>>  (define* (computed-file name gexp
>> -                        #:key guile (local-build? #t) (options '()))
>> +                        #:key (guile (%guile-for-build))
>> +                        (local-build? #t) (options '()))
>
> I think that would lead ‘computed-file’ to pick (%guile-for-build) at
> the wrong time (time of call instead of time of lowering).
>
> Commit ab25eb7caaf5571cc9f8d6397a1eae127d7e29d1 made it #f such that
> ‘gexp->derivation’ gets to resolve it at the “right” time.

I see!  I think you are right.  Would making the change in the
associated gexp compiler do the right thing?  Currently it ignores the
%guile-for-build fluid as set in the tests/pack.scm test suite for
example.  Something like this:

--8<---------------cut here---------------start------------->8---
modified   guix/gexp.scm
@@ -584,7 +584,7 @@ (define-record-type <computed-file>
   (options    computed-file-options))             ;list of arguments
 
 (define* (computed-file name gexp
-                        #:key (guile (%guile-for-build))
+                        #:key guile
                         (local-build? #t) (options '()))
   "Return an object representing the store item NAME, a file or directory
 computed by GEXP.  When LOCAL-BUILD? is #t (the default), it ensures the
@@ -601,7 +601,8 @@ (define-gexp-compiler (computed-file-compiler (file <computed-file>)
   ;; gexp.
   (match file
     (($ <computed-file> name gexp guile options)
-     (mlet %store-monad ((guile (lower-object (or guile (default-guile))
+     (mlet %store-monad ((guile (lower-object (or guile (%guile-for-build)
+                                                  (default-guile))
                                               system #:target #f)))
        (apply gexp->derivation name gexp #:guile-for-build guile
               #:system system #:target target options)))))
--8<---------------cut here---------------end--------------->8---

I've verified that 'make check TESTS=tests/pack.scm' is still happy
(without such patch, with patch 3/5 applied, the
"self-contained-tarball" would try to build a non-bootstrap guile and
timeout (on my old machine).

Thanks and enjoy FOSDEM!

-- 
Maxim

[bug#61255] [PATCH 0/5] Add support for the RPM format to "guix pack"

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello!
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> * guix/gexp.scm (computed-file): Set the default value of the #:guile argument
>>> to that of the %guile-for-build parameter.
>>
>> [...]
>>
>>>  (define* (computed-file name gexp
>>> -                        #:key guile (local-build? #t) (options '()))
>>> +                        #:key (guile (%guile-for-build))
>>> +                        (local-build? #t) (options '()))
>>
>> I think that would lead ‘computed-file’ to pick (%guile-for-build) at
>> the wrong time (time of call instead of time of lowering).
>>
>> Commit ab25eb7caaf5571cc9f8d6397a1eae127d7e29d1 made it #f such that
>> ‘gexp->derivation’ gets to resolve it at the “right” time.
>
> I see!  I think you are right.  Would making the change in the
> associated gexp compiler do the right thing?  Currently it ignores the
> %guile-for-build fluid as set in the tests/pack.scm test suite for
> example.  Something like this:

I don’t fully understand the context.  My preference would go to doing
like the ‘computed-file’ tests in ‘tests/gexp.scm’, where we explicitly
pass #:guile %bootstrap-guile.

That said, it seems like patch #5 in this series doesn’t actually use
‘computed-file’ in ‘tests/pack.scm’, does it?

Thanks,
Ludo’, slowly catching up post-FOSDEM!

[bug#61255] [PATCH 0/5] Add support for the RPM format to "guix pack"

[Maxim Cournoyer]

Hi Ludovic!

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hello!
>>>
>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>>
>>>> * guix/gexp.scm (computed-file): Set the default value of the #:guile argument
>>>> to that of the %guile-for-build parameter.
>>>
>>> [...]
>>>
>>>>  (define* (computed-file name gexp
>>>> -                        #:key guile (local-build? #t) (options '()))
>>>> +                        #:key (guile (%guile-for-build))
>>>> +                        (local-build? #t) (options '()))
>>>
>>> I think that would lead ‘computed-file’ to pick (%guile-for-build) at
>>> the wrong time (time of call instead of time of lowering).
>>>
>>> Commit ab25eb7caaf5571cc9f8d6397a1eae127d7e29d1 made it #f such that
>>> ‘gexp->derivation’ gets to resolve it at the “right” time.
>>
>> I see!  I think you are right.  Would making the change in the
>> associated gexp compiler do the right thing?  Currently it ignores the
>> %guile-for-build fluid as set in the tests/pack.scm test suite for
>> example.  Something like this:
>
> I don’t fully understand the context.  My preference would go to doing
> like the ‘computed-file’ tests in ‘tests/gexp.scm’, where we explicitly
> pass #:guile %bootstrap-guile.

With the refactoring done in patch 3/5 ("pack: Extract
populate-profile-root from self-contained-tarball/builder."), a
computed-file is used in the factorized building block
'populate-profile-root'.  Without this patch, the tests making use of it
would attempt to build Guile & friends in the test store.

> That said, it seems like patch #5 in this series doesn’t actually use
> ‘computed-file’ in ‘tests/pack.scm’, does it?

It does, indirectly.

I hope that helps!

-- 
Thanks,
Maxim

[bug#61255] (%guile-for-build) default in ‘computed-file’

[Ludovic Courtès]

Hello!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Hi Ludovic!
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> Hello!
>>>>
>>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>>>
>>>>> * guix/gexp.scm (computed-file): Set the default value of the #:guile argument
>>>>> to that of the %guile-for-build parameter.
>>>>
>>>> [...]
>>>>
>>>>>  (define* (computed-file name gexp
>>>>> -                        #:key guile (local-build? #t) (options '()))
>>>>> +                        #:key (guile (%guile-for-build))
>>>>> +                        (local-build? #t) (options '()))
>>>>
>>>> I think that would lead ‘computed-file’ to pick (%guile-for-build) at
>>>> the wrong time (time of call instead of time of lowering).
>>>>
>>>> Commit ab25eb7caaf5571cc9f8d6397a1eae127d7e29d1 made it #f such that
>>>> ‘gexp->derivation’ gets to resolve it at the “right” time.
>>>
>>> I see!  I think you are right.  Would making the change in the
>>> associated gexp compiler do the right thing?  Currently it ignores the
>>> %guile-for-build fluid as set in the tests/pack.scm test suite for
>>> example.  Something like this:
>>
>> I don’t fully understand the context.  My preference would go to doing
>> like the ‘computed-file’ tests in ‘tests/gexp.scm’, where we explicitly
>> pass #:guile %bootstrap-guile.
>
> With the refactoring done in patch 3/5 ("pack: Extract
> populate-profile-root from self-contained-tarball/builder."), a
> computed-file is used in the factorized building block
> 'populate-profile-root'.  Without this patch, the tests making use of it
> would attempt to build Guile & friends in the test store.
>
>> That said, it seems like patch #5 in this series doesn’t actually use
>> ‘computed-file’ in ‘tests/pack.scm’, does it?
>
> It does, indirectly.
>
> I hope that helps!

I’m really not sure what the impact of
68775338a510f84e63657ab09242d79e726fa457 is, nor whether it was the only
solution to the problem.

One thing that probably happens is that (default-guile) is now never
used for <computed-file>, contrary to what was happening before.  The
spirit is that (default-guile) would be used as the default for all the
declarative file-like objects; gexp compilers refer to (default-guile),
not (%guile-for-build).

Importantly, (%guile-for-build) is a derivation, possibly built for
another system, whereas (default-guile) is a package, which allows
‘lower-object’ to return the derivation for the right system type.

Overall, I think this change should be reverted but of course, we should
find a solution to the problem you hit in the first place.

I hope this makes sense to you.

Ludo’.

bug#61841: bug#61255: [PATCH 0/5] Add support for the RPM format to "guix pack"

[Ludovic Courtès]

Hi Maxim,

Ludovic Courtès <ludo@gnu.org> skribis:

> I’m really not sure what the impact of
> 68775338a510f84e63657ab09242d79e726fa457 is, nor whether it was the only
> solution to the problem.
>
> One thing that probably happens is that (default-guile) is now never
> used for <computed-file>, contrary to what was happening before.  The
> spirit is that (default-guile) would be used as the default for all the
> declarative file-like objects; gexp compilers refer to (default-guile),
> not (%guile-for-build).
>
> Importantly, (%guile-for-build) is a derivation, possibly built for
> another system, whereas (default-guile) is a package, which allows
> ‘lower-object’ to return the derivation for the right system type.

Commit 68775338a510f84e63657ab09242d79e726fa457 turned out to have
unintended side effects:

  https://issues.guix.gnu.org/61841

I fixed it with:

  a516a0ba93 gexp: computed-file: Do not honor %guile-for-build.
  fee1d08f0d pack: Make sure tests can run without a world rebuild.

Please take a look.

We should think about how to improve our processes to avoid such issues
in the future.  I did raise concerns about this very patch late at night
during FOSDEM, 24h after submission, and reaffirmed my viewpoint days
later.  I understand that delaying a nice patch series like this one is
unpleasant, but I think those concerns should have been taken into
account.

Ludo’.

bug#61841: bug#61255: [PATCH 0/5] Add support for the RPM format to "guix pack"

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Maxim,
>
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> I’m really not sure what the impact of
>> 68775338a510f84e63657ab09242d79e726fa457 is, nor whether it was the only
>> solution to the problem.
>>
>> One thing that probably happens is that (default-guile) is now never
>> used for <computed-file>, contrary to what was happening before.  The
>> spirit is that (default-guile) would be used as the default for all the
>> declarative file-like objects; gexp compilers refer to (default-guile),
>> not (%guile-for-build).
>>
>> Importantly, (%guile-for-build) is a derivation, possibly built for
>> another system, whereas (default-guile) is a package, which allows
>> ‘lower-object’ to return the derivation for the right system type.
>
> Commit 68775338a510f84e63657ab09242d79e726fa457 turned out to have
> unintended side effects:
>
>   https://issues.guix.gnu.org/61841

Ugh.

> I fixed it with:
>
>   a516a0ba93 gexp: computed-file: Do not honor %guile-for-build.
>   fee1d08f0d pack: Make sure tests can run without a world rebuild.
>
> Please take a look.

Thank you.  I still think it'd be nicer if computed-file had a means to
honor %guile-for-build rather than having to accommodate it specially as
you did in fee1d08f0d, so that it'd be symmetrical to gexp->derivation
in that regard.  Why can't they?

> We should think about how to improve our processes to avoid such issues
> in the future.  I did raise concerns about this very patch late at night
> during FOSDEM, 24h after submission, and reaffirmed my viewpoint days
> later.  I understand that delaying a nice patch series like this one is
> unpleasant, but I think those concerns should have been taken into
> account.

You are right, I should have delayed this submission passed its 2 weeks,
to let some extra time to look at alternatives w.r.t. the
%guile-for-build patch.  Apologies for being too eager!

-- 
Thanks,
Maxim

bug#61841: ‘guix shell’ computes different package derivation than ‘guix build’

[Ludovic Courtès]

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> Commit 68775338a510f84e63657ab09242d79e726fa457 turned out to have
>> unintended side effects:
>>
>>   https://issues.guix.gnu.org/61841
>
> Ugh.
>
>> I fixed it with:
>>
>>   a516a0ba93 gexp: computed-file: Do not honor %guile-for-build.
>>   fee1d08f0d pack: Make sure tests can run without a world rebuild.
>>
>> Please take a look.
>
> Thank you.  I still think it'd be nicer if computed-file had a means to
> honor %guile-for-build rather than having to accommodate it specially as
> you did in fee1d08f0d, so that it'd be symmetrical to gexp->derivation
> in that regard.  Why can't they?

Like I wrote, ‘default-guile’ returns a package whereas
‘%guile-for-build’ returns a derivation.

The latter is inherently lower-level: it’s used together with the
monadic interface or with plain ‘derivation’, when we know which system
we’re targeting.  The former is higher-level, system-independent; it
must be used for <computed-file> and similar forms, which are
system-independent.

Ludo’.

bug#61841: ‘guix shell’ computes different package derivation than ‘guix build’

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> Commit 68775338a510f84e63657ab09242d79e726fa457 turned out to have
>>> unintended side effects:
>>>
>>>   https://issues.guix.gnu.org/61841
>>
>> Ugh.
>>
>>> I fixed it with:
>>>
>>>   a516a0ba93 gexp: computed-file: Do not honor %guile-for-build.
>>>   fee1d08f0d pack: Make sure tests can run without a world rebuild.
>>>
>>> Please take a look.
>>
>> Thank you.  I still think it'd be nicer if computed-file had a means to
>> honor %guile-for-build rather than having to accommodate it specially as
>> you did in fee1d08f0d, so that it'd be symmetrical to gexp->derivation
>> in that regard.  Why can't they?
>
> Like I wrote, ‘default-guile’ returns a package whereas
> ‘%guile-for-build’ returns a derivation.
>
> The latter is inherently lower-level: it’s used together with the
> monadic interface or with plain ‘derivation’, when we know which system
> we’re targeting.  The former is higher-level, system-independent; it
> must be used for <computed-file> and similar forms, which are
> system-independent.

I see, it's starting to make sense.  I'll sleep on it :-).

-- 
Thanks,
Maxim