Changes to GHC that will expose new packages

[Mark Lentczner]

I'm lost as to where this has gone.... We all agree that any distro package
for the GHC system is going to include both ghc and ghci. Further, the two
are rather intimately linked in source and in compiled executable and
library. Hence, I don't see a short term practical reason for splitting
them..

Back to the main situation:

   - There are changes to ghci that will require it to depend on four new
   packages that GHC didn't need before: haskeline, mtl, terminfo &
   utf8-string.
   - Since ghc is offered as a library as well as an executable, ghc will
   need to ship with these four additional packages.
   - Version concerns will only affect users that include ghc as part of
   their project.They will end up tied to particular versions of mtl,
   haskeline, terminfo, & utf8-string. (This is true even if the ghc/ghci APIs
   don't expose any types from those packages.)
   - For projects that don't link against ghc, (most projects), the
   versions of these packages are irrelevant. ghc-pkg and cabal can happily
   resolve to using a different version of mtl if the user's project needs it.
   (*)

The issues for HP I think are just these:

   1. The version of mtl in ghc would force the version in HP. This isn't
   really a problem so long as the same stance on stability is taken.
   2. HP probably wouldn't decide to include haskeline and terminfo as
   "batteries included". That ghc will force them into the set isn't a huge
   deal, but something everyone needs to be aware of: GHC can effectively
   force a package.
   3. While I think haskeline and terminfo will not have a big effect,
   utf8-string is a sad regression. I don't think that we'll be happy stating
   that as part of the "batteries included", as we feel Text is the long term
   position. I'm assuming that haskeline use of utf8-string is the reason? Any
   chance we can get haskeline rev'd to use text?

Finally, a question of timing: Which version of GHC is this planned for? We
are coming up on the next HP release, and we need to start fixing which
versions of things will be included.

- Mark

* I suppose that in some distros there is tension between ghc package
manegment and the host OS's package manager: If you want to have a distro
package for thing A that requires haskell package B, then B needs to be
distro'd in a host package. If B moves from one distro package (haskell-b)
to another (ghc, say), then yes the dependencies are a problem. But this
strikes me as a problem of the interplay between two package systems, and I
don't know that we can have a good solution that works in all cases here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20120325/a54f0663/attachment.htm>