From Fedora Project Wiki
(initial content) |
m (fix numbered items) |
||
| Line 11: | Line 11: | ||
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. | ||
# 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) | |||
Revision as of 06:11, 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 an intensive 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 all the haskell-sig packages. 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)