unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10
@ 2022-01-10 16:15 zimoun
  2022-01-11 10:18 ` Ludovic Courtès
  0 siblings, 1 reply; 4+ messages in thread
From: zimoun @ 2022-01-10 16:15 UTC (permalink / raw)
  To: 53162

Hi,

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

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

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,

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

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

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

However, tandam!

--8<---------------cut here---------------start------------->8---
$ 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
--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@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




^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10
  2022-01-10 16:15 bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10 zimoun
@ 2022-01-11 10:18 ` Ludovic Courtès
  2022-01-11 10:33   ` zimoun
  0 siblings, 1 reply; 4+ messages in thread
From: Ludovic Courtès @ 2022-01-11 10:18 UTC (permalink / raw)
  To: zimoun; +Cc: 53162

Hi,

zimoun <zimon.toutoune@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@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’.




^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10
  2022-01-11 10:18 ` Ludovic Courtès
@ 2022-01-11 10:33   ` zimoun
  2022-01-11 13:19     ` Ludovic Courtès
  0 siblings, 1 reply; 4+ messages in thread
From: zimoun @ 2022-01-11 10:33 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 53162

Hi,

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.

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




^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10
  2022-01-11 10:33   ` zimoun
@ 2022-01-11 13:19     ` Ludovic Courtès
  0 siblings, 0 replies; 4+ messages in thread
From: Ludovic Courtès @ 2022-01-11 13:19 UTC (permalink / raw)
  To: zimoun; +Cc: 53162

Hi,

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

> 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.

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




^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-01-11 13:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-10 16:15 bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10 zimoun
2022-01-11 10:18 ` Ludovic Courtès
2022-01-11 10:33   ` zimoun
2022-01-11 13:19     ` Ludovic Courtès

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).