From Fedora Project Wiki

No edit summary
Line 10: Line 10:


For a branched release a version update and all consequent rebuilds of ghc-* etc needs to be done in a separate buildroot dist-fX-ghc to avoid disruption and repo breakage.
For a branched release a version update and all consequent rebuilds of ghc-* etc needs to be done in a separate buildroot dist-fX-ghc to avoid disruption and repo breakage.
== Steps ==


# Build the new ghc version (in dist-fX-ghc if it is for a branched release)
# Build the new ghc version (in dist-fX-ghc if it is for a branched release)

Revision as of 06:14, 25 March 2011

SOP for updating GHC in Fedora

Note this page is still a draft and work in progress.

Updating GHC to a new version is a heavy operation and should be done with due care and consideration. You probably also need to be a provenpackager or at least have commit access to most of the haskell-sig packages and/or coordinate with haskell-sig contributors. Note further that the current stable haskell-platform release dictates the current stable version of ghc.

Generally we do not update ghc version in stable releases without a good reason because of the large overhead of rebuilding everything.

For a branched release a version update and all consequent rebuilds of ghc-* etc needs to be done in a separate buildroot dist-fX-ghc to avoid disruption and repo breakage.

Steps

  1. Build the new ghc version (in dist-fX-ghc if it is for a branched release)
  2. Rebuild hscolour against the new ghc
  3. Rebuild the new ghc version again to fix the ABI (note particularly the ghc API lib seems particularly ABI sensitive)
  4. Chain-build ghc-transformers and ghc-mtl
  5. Chain-build haskell-platform stack (use haskell-sig/rebuild/rebuild.sh)