Changes to GHC that will expose new packages

[Simon Peyton-Jones]

A question for Simon M.  The real underlying problem here (in my limited understanding) is that we distribute a HP containing a hidden mtl or uft8-string, used by GHC, but not messing up other users.

I know that we are close to solving this problem, with package stamps/signatures.

I know that we also have more ambitious plans for overhauling the package mechanism.

But how hard would it be to solve this particular wart, and thereby make things much smoother?

Simon

From: haskell-platform-bounces at projects.haskell.org [mailto:haskell-platform-bounces at projects.haskell.org] On Behalf Of Mark Lentczner
Sent: 25 March 2012 20:48
To: Ross Paterson
Cc: haskell-platform at projects.haskell.org
Subject: Re: Changes to GHC that will expose new packages

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/20120326/95e67371/attachment-0001.htm>