From Fedora Project Wiki
No edit summary |
|||
| Line 3: | Line 3: | ||
''Note this page is still a draft and work in progress.'' | ''Note this page is still a draft and work in progress.'' | ||
Updating GHC to a new version is | 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 | 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. | Note further that the current stable haskell-platform release dictates the current stable version of ghc. | ||
Revision as of 06:13, 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.
- Build the new ghc version (in dist-fX-ghc if it is for a branched release)
- Rebuild hscolour against the new ghc
- Rebuild the new ghc version again to fix the ABI (note particularly the ghc API lib seems particularly ABI sensitive)
- Chain-build ghc-transformers and ghc-mtl
- Chain-build haskell-platform stack (use haskell-sig/rebuild/rebuild.sh)