GNU bug report logs - #53162
’guix shell ghc@8.4’ downloads ghc@8.10

Previous Next

To reply to this bug, email your comments to 53162 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: ’guix shell ghc <at> 8.4’
 downloads ghc <at> 8.10
Date: Mon, 10 Jan 2022 17:15:55 +0100

Hi,

Using 3dcc74d, I get an unexpected behaviour.  First, all expected:

--8<---------------cut here---------------start------------->8---
$ guix build ghc <at> 8.10 -n
122,4 MB would be downloaded:
   /gnu/store/p8rk5cp1p4b2zky4zj1shfqb11qb5nmk-ghc-8.10.7-doc
   /gnu/store/i92h6i23rnvrvn7xva6w9x7gjkljmfws-ghc-8.10.7

$ guix build ghc <at> 8.4 -n
/gnu/store/5gp4k7ly1smhkx95rhq21nvxmyg687bv-ghc-8.4.4-doc
/gnu/store/wxfr2naibx3qpy4w243a7ga98mchf6g3-ghc-8.4.4
--8<---------------cut here---------------end--------------->8---

I have ghc <at> 8.4 in my local store, but not ghc <at> 8.10.  In addition, no
path between ghc <at> 8.4 and ghc <at> 8.10,

--8<---------------cut here---------------start------------->8---
$ guix graph --path ghc <at> 8.4 ghc <at> 8.10
guix graph: error: no path from 'ghc <at> 8.4.4' to 'ghc <at> 8.10.7'
--8<---------------cut here---------------end--------------->8---

Even, ghc <at> 8.4 is used in the bootstrap chain of ghc <at> 8.10,

--8<---------------cut here---------------start------------->8---
$ guix graph --path ghc <at> 8.10 ghc <at> 8.4
ghc <at> 8.10.7
ghc <at> 8.8.4
ghc <at> 8.6.5
ghc <at> 8.4.4
--8<---------------cut here---------------end--------------->8---

However, tandam!

--8<---------------cut here---------------start------------->8---
$ guix shell -C ghc <at> 8.4
The following derivation will be built:
   /gnu/store/rx0spryh76az0ll6ddy7f7hy8ykhglnh-profile.drv

117,7 MB will be downloaded
 ghc-8.10.7  112.3MiB                                                                                                         3.3MiB/s 00:01 [                  ]   1.9%  C-c C-c
--8<---------------cut here---------------end--------------->8---

From the profile.drv, the culprit is identified:
/gnu/store/…-ghc-package-cache.drv,

--8<---------------cut here---------------start------------->8---
Derive
([("out","/gnu/store/mcmwdg13f5rc9vdklgbmsn6h84bgdp3q-ghc-package-cache","","")]
 ,[("/gnu/store/8m7vppxy4l824yk4036iisk2zy7qzgcx-ghc-8.4.4.drv",["out"])
   ,("/gnu/store/bc5cm1g1b884nvgiysq8x0i0wxplkqhl-ghc-8.10.7.drv",["out"])
   ,("/gnu/store/m0nbbk3vgl637ibrz7z72r5v0dkswpi2-guile-3.0.7.drv",["out"])
   ,("/gnu/store/qcksap17gs36gpnjj3by4d7r7yxfq405-module-import-compiled.drv",["out"])]
 ,["/gnu/store/45dpf18lzvzs6sbmihifw6ch9p6y20yr-ghc-package-cache-builder","/gnu/store/4j2xcm5s0hvmpjm8fdbmb02ipvr6wyxn-module-import"]
 ,"x86_64-linux","/gnu/store/fidl08nms5v63lkqv627zibxpd85zxqb-guile-3.0.7/bin/guile",["--no-auto-compile","-L","/gnu/store/4j2xcm5s0hvmpjm8fdbmb02ipvr6wyxn-module-import","-C","/gnu/store/n7687sw6nkrhpjkdgysgz7baihzipgl0-module-import-compiled","/gnu/store/45dpf18lzvzs6sbmihifw6ch9p6y20yr-ghc-package-cache-builder"]
 ,[("allowSubstitutes","0")
   ,("guix properties","((type . profile-hook) (hook . ghc-package-cache))")
   ,("out","/gnu/store/mcmwdg13f5rc9vdklgbmsn6h84bgdp3q-ghc-package-cache")
   ,("preferLocalBuild","1")])
--8<---------------cut here---------------end--------------->8---


From my perspective, it is a bug from (guix profiles)
’ghc-package-cache-file’ which always includes ’ghc’, currently pointing
to ghc <at> 8.10.

--8<---------------cut here---------------start------------->8---
  (define ghc                                     ;lazy reference
    (module-ref (resolve-interface '(gnu packages haskell)) 'ghc))
--8<---------------cut here---------------end--------------->8---

Well, the fix is not jumping to my eyes.  If someone has an idea to
conditionally remove this reference to ’ghc’?


Cheers,
simon

Message #8 received at 53162 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 53162 <at> debbugs.gnu.org
Subject: Re: bug#53162: ’guix shell ghc <at> 8.4’ downloads ghc <at> 8.10
Date: Tue, 11 Jan 2022 11:18:01 +0100

Hi,

zimoun <zimon.toutoune <at> gmail.com> skribis:

>>From the profile.drv, the culprit is identified:
> /gnu/store/…-ghc-package-cache.drv,
>
> Derive
> ([("out","/gnu/store/mcmwdg13f5rc9vdklgbmsn6h84bgdp3q-ghc-package-cache","","")]
>  ,[("/gnu/store/8m7vppxy4l824yk4036iisk2zy7qzgcx-ghc-8.4.4.drv",["out"])
>    ,("/gnu/store/bc5cm1g1b884nvgiysq8x0i0wxplkqhl-ghc-8.10.7.drv",["out"])
>    ,("/gnu/store/m0nbbk3vgl637ibrz7z72r5v0dkswpi2-guile-3.0.7.drv",["out"])
>    ,("/gnu/store/qcksap17gs36gpnjj3by4d7r7yxfq405-module-import-compiled.drv",["out"])]
>  ,["/gnu/store/45dpf18lzvzs6sbmihifw6ch9p6y20yr-ghc-package-cache-builder","/gnu/store/4j2xcm5s0hvmpjm8fdbmb02ipvr6wyxn-module-import"]
>  ,"x86_64-linux","/gnu/store/fidl08nms5v63lkqv627zibxpd85zxqb-guile-3.0.7/bin/guile",["--no-auto-compile","-L","/gnu/store/4j2xcm5s0hvmpjm8fdbmb02ipvr6wyxn-module-import","-C","/gnu/store/n7687sw6nkrhpjkdgysgz7baihzipgl0-module-import-compiled","/gnu/store/45dpf18lzvzs6sbmihifw6ch9p6y20yr-ghc-package-cache-builder"]
>  ,[("allowSubstitutes","0")
>    ,("guix properties","((type . profile-hook) (hook . ghc-package-cache))")
>    ,("out","/gnu/store/mcmwdg13f5rc9vdklgbmsn6h84bgdp3q-ghc-package-cache")
>    ,("preferLocalBuild","1")])
>
>
>
>>From my perspective, it is a bug from (guix profiles)
> ’ghc-package-cache-file’ which always includes ’ghc’, currently pointing
> to ghc <at> 8.10.
>
>   (define ghc                                     ;lazy reference
>     (module-ref (resolve-interface '(gnu packages haskell)) 'ghc))
>
> Well, the fix is not jumping to my eyes.  If someone has an idea to
> conditionally remove this reference to ’ghc’?

Is it a problem that the latest GHC is used to build the package cache?
(Apart from being surprising and suboptimal.)

Some profile hooks, such as ‘gdk-pixbuf-loaders-cache-file’, use the
package available in the closure (gdk-pixbuf in this case) rather than
the latest version.  It’s a bit of a hack, but if required, we could do
that.

Ludo’.

Message #11 received at 53162 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 53162 <at> debbugs.gnu.org
Subject: Re: bug#53162: ’guix shell ghc <at> 8.4’ downloads ghc <at> 8.10
Date: Tue, 11 Jan 2022 11:33:33 +0100

Hi,

On Tue, 11 Jan 2022 at 11:18, Ludovic Courtès <ludo <at> gnu.org> wrote:

> Is it a problem that the latest GHC is used to build the package cache?
> (Apart from being surprising and suboptimal.)

Functionally, it appears to be not a blocking problem.  However,
suboptimal means concretely 110+ MB of additional download; well it just
doubles the size of the download.

About the surprise, if one is confident with their Guix skill, then they
look for a bug Guix-side; if one is less confident, then they look for a
twist in their config.  In both cases, it is a diversion – let as the
reader’s judgment if this diversion is fun or a waste of time. :-)


> Some profile hooks, such as ‘gdk-pixbuf-loaders-cache-file’, use the
> package available in the closure (gdk-pixbuf in this case) rather than
> the latest version.  It’s a bit of a hack, but if required, we could do
> that.

What other Haskellers think about the issue?  Fix or document this
surprising behaviour?


Cheers,
simon

Message #14 received at 53162 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 53162 <at> debbugs.gnu.org
Subject: Re: bug#53162: ’guix shell ghc <at> 8.4’ downloads ghc <at> 8.10
Date: Tue, 11 Jan 2022 14:19:00 +0100

Hi,

zimoun <zimon.toutoune <at> gmail.com> skribis:

> On Tue, 11 Jan 2022 at 11:18, Ludovic Courtès <ludo <at> gnu.org> wrote:
>
>> Is it a problem that the latest GHC is used to build the package cache?
>> (Apart from being surprising and suboptimal.)
>
> Functionally, it appears to be not a blocking problem.  However,
> suboptimal means concretely 110+ MB of additional download; well it just
> doubles the size of the download.

Understood.

> About the surprise, if one is confident with their Guix skill, then they
> look for a bug Guix-side; if one is less confident, then they look for a
> twist in their config.  In both cases, it is a diversion – let as the
> reader’s judgment if this diversion is fun or a waste of time. :-)

Yes, but that’s not very different from installing mpv and setting
downloads of ffmpeg, rav1e, rust, and all sorts of things the user
doesn’t necessarily know about.

So to me we should first look at (1) compatibility (make sure the
package cache is valid), and (2) efficiency (avoid downloading too
much).

Ludo’.

Message #19 received at 53162-done <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: 53162-done <at> debbugs.gnu.org
Subject: Close
Date: Mon, 28 Jul 2025 22:54:11 +0200

Closing as there does not seem to be any actionable idea for progress.

Andreas

Message #24 received at 53162 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: help-debbugs <at> gnu.org (GNU bug Tracking System)
Cc: andreas <at> enge.fr, 53162 <at> debbugs.gnu.org
Subject: Re: bug#53162: ’guix shell ghc <at> 8.4’ downloads ghc <at> 8.10
Date: Mon, 18 Aug 2025 10:05:20 +0200

Hi Andreas,

I’m reopening #53162:

    https://issues.guix.gnu.org/issue/53162

Just to comment on. :-)  And I’ll close it right after!

> Closing…

IMHO, the bug (unexpected behaviour) is still there!

As you noticed once, IIRC, this annoyance matters on powerless hardware
because we have this chain of dependencies:

        $ guix graph --path ghc <at> 8.10 ghc <at> 8.4
        ghc <at> 8.10.7
        ghc <at> 8.8.4
        ghc <at> 8.6.5
        ghc <at> 8.4.4

and therefore, if there is no substitute, then it needs to build all.

Ok, that’s the game of bootstrapping. :-) However, the current design
implies to also pass all the lengthy Haskell test suite.

Well, for the record, I point this old thread [1].  From my
remembering, I did some stuff in that direction but I’ve probably lost
the branch… Arf!


> ………………………… there does not seem to be any actionable idea for progress.

The two actionable cut-corner steps are:

   1. Make the test suite separate

     e.g., if the lenghty and intensive test suite of GHC <at> 8.4.4 fails,
     then it isn’t blocking for trying to build the rest.

   2. Cut a bit the chain, as explained in [1]


Well, these cut-the-corners are two overdues [2] and this report was a
kind of reminder. :-)  For sure, fine to keep it close and track the
progress directly on Codeberg.

Thanks for raising this up… :-D


Cheers,
simon


1: Re: Core-updates after the staging merge
Simon Tournier <zimon.toutoune <at> gmail.com>
Mon, 17 Apr 2023 14:19:43 +0200
id:87r0siem5c.fsf <at> gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-04
https://yhetil.org/guix/87r0siem5c.fsf <at> gmail.com

2: Re: Core-updates after the staging merge
Andreas Enge <andreas <at> enge.fr>
Mon, 17 Apr 2023 11:03:25 +0200
id:ZD0LXefP6X4TiYYF <at> jurong
https://lists.gnu.org/archive/html/guix-devel/2023-04
https://yhetil.org/guix/ZD0LXefP6X4TiYYF <at> jurong

Previous Next

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