| Message ID | c4f97924d832d52aa15366b4e2397568e2d96868.1703056111.git.saku@laesvuori.fi |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#67921,haskell-team,1/3] gnu: ghc-next: Update to version 9.4.8 | expand |
Hi,
> * gnu/packages/haskell.scm (ghc-9.4): Rename from ghc-next to ghc.
why 9.4 and not 9.6? Stackage 22.0 for 9.6 has just been released and
if we go for a big upgrade (you’ll have to update the entire Haskell
ecosystem if you update GHC), we might as well just make the jump to
GHC 9.6 and Stackage 22.0.
Lars
> Hi, > > > * gnu/packages/haskell.scm (ghc-9.4): Rename from ghc-next to ghc. > > why 9.4 and not 9.6? Stackage 22.0 for 9.6 has just been released and > if we go for a big upgrade (you’ll have to update the entire Haskell > ecosystem if you update GHC), we might as well just make the jump to > GHC 9.6 and Stackage 22.0. Because I wrote that patch when there wasn't yet a Stackage release for ghc 9.6. But if a stackage release for it has now been released I'll try updating it to 9.6. Regarding the big upgrade, I have been wondering how could the cabal revisions be updated automatically. Is there a simpler way than to 1. include a procedure for editing the declaration in the <upstream-updater> 2. refactor the entire updater code to use that procedure 3. implement completely new logic for adding fields to package definitions? That seems like a lot of work in code that I don't know all that well. Is there some reason why the revision is not part of the package version? Moving it there would probably be much easier than modifying guix refresh (but then again, if those modifications should be done anyway it doesn't really reduce the amount of work) - Saku
Hi Saku, > Because I wrote that patch when there wasn't yet a Stackage release for > ghc 9.6. But if a stackage release for it has now been released I'll try > updating it to 9.6. oh, I see. I believe 9.6 drops the Makefile-based build-system, making it a slightly more involved upgrade. > Regarding the big upgrade, I have been wondering how could the cabal > revisions be updated automatically. I’ve been using the script attached, which basically overwrites the entire package, except for synopsis and description. > Is there some reason why the revision is not part of the package > version? I don’t know. > Moving it there would probably be much easier than modifying > guix refresh (but then again, if those modifications should be done > anyway it doesn't really reduce the amount of work) The thing is that we still need the cabal file hash somewhere and it needs to be updated. My idea was to create a new HACKAGE-URI procedure, which accepts package name, version, revision and cabal file hash and add some black magic to combine the new cabal file with the tarball from hackage. Code exists for this, but I’ve never been able to finalize it. Lars
diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm index 88826fb31f..ebe5bc6dc8 100644 --- a/gnu/packages/haskell.scm +++ b/gnu/packages/haskell.scm @@ -1392,12 +1392,6 @@ (define-public ghc-9.2 (file-pattern ".*\\.conf\\.d$") (file-type 'directory))))))) -;; Versions newer than ghc defined below (i.e. the compiler -;; haskell-build-system uses) should use ghc-next as their name to -;; ensure ghc (without version specification) and ghc-* packages are -;; always compatible. See https://issues.guix.gnu.org/issue/47335. -(define-public ghc ghc-9.2) - ;; 9.4 is the last version to support the make-based build system, ;; but it boot with 9.2, only 9.0 is supported. (define ghc-bootstrap-for-9.4 ghc-9.0) @@ -1461,7 +1455,7 @@ (define-public ghc-9.4 (let ((base ghc-9.2)) (package (inherit base) - (name "ghc-next") + (name "ghc") (version "9.4.8") (source (origin (method url-fetch) @@ -1503,4 +1497,10 @@ (define-public ghc-9.4 (file-pattern ".*\\.conf\\.d$") (file-type 'directory))))))) +;; Versions newer than ghc defined below (i.e. the compiler +;; haskell-build-system uses) should use ghc-next as their name to +;; ensure ghc (without version specification) and ghc-* packages are +;; always compatible. See https://issues.guix.gnu.org/issue/47335. +(define-public ghc ghc-9.4) + ;;; haskell.scm ends here