| Author: | Lennart Kolmodin <kolmodin@gentoo.org>, Gentoo Haskell Herd <haskell@gentoo.org> |
|---|---|
| Updated: | 2007-07-23 |
Due to the restructure of bundled libraries from GHC 6.4 -> 6.6 we've had to rewrite ebuild dependencies between packages and libraries. While doing this we have also taken the chance to do some updates we've been ponding on in the past.
This document describes some background on what's new in GHC 6.6 and the plan that has been carefully crafted on how to deal with it.
We have tried to summarize what the Gentoo Haskell Heard has been up to the past months (or year...).
In GHC 6.4 a lot of packages where bundled with the compiler. In GHC 6.6 this has changed, all but the packages used by the compiler itself are now available as a separate download. That bundle is called ghc-extralibs.
This makes the GHC installation much faster, as you only compile the libs you need. Also, it gives the advantage that when you'd like to update a library, you only have to recompile exactly that one, instead of recompiling everything like before.
We have also merged the dev-lang/ghc-bin package into the dev-lang/ghc package, which you can get by using USE=binary. The ghc-bin tarball is used to bootstrap the source ghc compiler, instead of relying on a preinstalled compiler.
This can be modeled in Gentoo Linux' package management system, as we'll see next.
Each library in the ghc-extralibs will be represented by a separate package in the tree. Packages that can be compiled with GHC 6.6 (possibly also GHC 6.4) should depend on the modular libraries.
To mirror this behavior for GHC 6.4 where the compiler already provides the libraries, we use dummy libraries as place holders. They will not do or install anything, but merely exist to depended upon by packages that need those libraries. The dummy libraries will only depend on the GHC 6.4 compiler, while the real modular libs will depend on the GHC 6.6 series or newer. If an application/library is compiled against GHC 6.4 the dummy libraries will be used, and in the case of GHC 6.6 the modular libraries. This way it'll be easy to write the ebuilds, just depend on the libraries you need, regardless of compiler version.
Note though, packages that cannot be built with GHC 6.6 doesn't gain anything from depending on the modular libraries, as they are guarantied to all be dummy libraries. Thus there should be no requirement for those packages to use the modular libs.
It makes dependienceies simpler...:
DEPEND="=virtual/ghc-6.4* !>=virtual/ghc-6.6"
Assume the user has ghc-bin-6.4.2 which he (or she!) used to compile ghc-6.4.2, and then one day installs ghc-6.6. The first dependency will be satisfied by ghc-bin-6.4.2, but it's actually ghc-6.6 that's going to be used to compile the package! (as ghc has precedence to ghc-bin). The block makes sure this doesn't happen.
With ghc only available as one package, you can simply say:
DEPEND="=dev-lang/ghc-6.4*"
The proposed actions of the scheme are listed below.
This was done 7 March. It's p.masked.
Update 2007-03-16: ghc-bin-6.6 in the tree, ~amd64 ~x86
Update 2007-04-12: cparrot has added ~alpha, ~ppc and ~sparc
Ie, only the modular libs from ghc-extralibs meant for GHC 6.6. They should also be p.masked.
Modular libs has been added for:
Still missing for:
The about 15 packages of ghc-extralibs has to be modeled as dummy libs too. They should be added as ~arch and then be stabilized by the arch teams asap.
The most common libs where added the 11th March, and have been marked as ~arch or stable on 2007-04-02:
Dummies missing, just as all dummies, they only has to be added if an ebuild depends on that functionality:
This is only required for applications that can be compiled with GHC 6.6, as described above.
Packages that today are marked as stable and can be compiled with GHC 6.6 requires that the dummy libraries are marked as stable too. Thus we have to start rewriting the other packages until the dummys has been marked stable.
Packages that only compiles with GHC 6.6 can be added to, if p.masked.