’guix shell ghc@8.4’ downloads ghc@8.10

  • Open
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • zimoun
Owner
unassigned
Submitted by
zimoun
Severity
normal
Z
Z
zimoun wrote on 10 Jan 2022 17:15
(address . bug-guix@gnu.org)
87zgo3woqs.fsf@gmail.com
Hi,

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

Toggle snippet (10 lines)
$ guix build ghc@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@8.4 -n
/gnu/store/5gp4k7ly1smhkx95rhq21nvxmyg687bv-ghc-8.4.4-doc
/gnu/store/wxfr2naibx3qpy4w243a7ga98mchf6g3-ghc-8.4.4

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

Toggle snippet (4 lines)
$ guix graph --path ghc@8.4 ghc@8.10
guix graph: error: no path from 'ghc@8.4.4' to 'ghc@8.10.7'

Even, ghc@8.4 is used in the bootstrap chain of ghc@8.10,

Toggle snippet (7 lines)
$ guix graph --path ghc@8.10 ghc@8.4
ghc@8.10.7
ghc@8.8.4
ghc@8.6.5
ghc@8.4.4

However, tandam!

Toggle snippet (8 lines)
$ guix shell -C ghc@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

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

Toggle snippet (15 lines)
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@8.10.

Toggle snippet (4 lines)
(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’?


Cheers,
simon
L
L
Ludovic Courtès wrote on 11 Jan 2022 11:18
Re: bug#53162: ’guix shell ghc@8 .4’ downloads ghc@8.10
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 53162@debbugs.gnu.org)
87wnj6wp7q.fsf@gnu.org
Hi,

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

Toggle quote (28 lines)
>>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@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’.
Z
Z
zimoun wrote on 11 Jan 2022 11:33
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 53162@debbugs.gnu.org)
86lezm4l4y.fsf@gmail.com
Hi,

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

Toggle quote (3 lines)
> 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. :-)


Toggle quote (5 lines)
> 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
L
L
Ludovic Courtès wrote on 11 Jan 2022 14:19
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 53162@debbugs.gnu.org)
87wnj6tnp7.fsf@gnu.org
Hi,

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

Toggle quote (9 lines)
> On Tue, 11 Jan 2022 at 11:18, Ludovic Courtès <ludo@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.

Toggle quote (5 lines)
> 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’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 53162@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 53162
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch