Greetings and Haskell Platform

[Clemens Lang]

On Mon, Dec 24, 2012 at 04:18:47PM +1100, Andy Kitchen wrote:
> I'm a new committer, so, Hi everyone.

Hi and welcome to the MacPorts project! :)

> Wrt. The Haskell platform, it's a priority for me to get the macports
> Haskell platform up-to-date and have an easy way to keep it up to
> date.
> 
> To this end, I've been thinking that the individual packages approach
> that is currently used (ie. one package for each library needed by the
> Haskell platform) is flawed.
> 
> The Haskell platform people provide a source tar-ball of the Haskell-
> platform with source for all dependencies and build scripts included.
> In my opinion the most sustainable way of keeping the HP port up-to-
> date is to wrap a port around this tarball.

Does this also include GHC? I can imagine some people might want to
install GHC without the platform (though, admittedly, the build time and
size is quite short compared to GHC's).

> Pros:
> - Haskell Platform source tarball already has a ./configure and
>   make setup that is easy to wrap in a port.
> - No more hassles with micro dependency management of
>   2 dozen packages.

While it is true that we wouldn't need to care about the dependency
management within the platform and towards the platform, we'd still have
to deal with this in all the other hs-* packages (i.e., those not in the
platform).
If we're going to automate that keeping the separate hs-platform-* ports
around isn't much of a hassle either.

> When the Haskell platform is updated the whole thing will have to be
> rebuilt instead of just the libraries that have had their versions
> bumped.

If the GHC version changes we need to trigger a rebuild of those ports
that didn't have their version increased anyway.

> There are also some more complicated issues as well, basically the
> versioning system that the haskell package manager (cabal) uses is
> different to the macports one. So capturing the dependency structure
> of cabal packages with portfiles is impossible and will inevitably
> lead to bugs.

While it is true we cannot represent the full dependency information of
cabal packages, I didn't have any problems yet mapping the dependency
information to something that would satisfy the dependencies in
MacPorts. All version comparisons could be statically resolved when
writing the port using the versions currently available in MacPorts.
Flags might be a problem, though…

> So trying to keep the hs-* packages working is a tricky business. I
> don't think this is overall a good idea. Long term it might be good to
> transition to hs-* packages just being shims that call into
> cabal-install.

That would be a good solution, if we can ensure cabal-install always
installs a specific version and if we can make it install via a
destroot, so MacPorts can keep track of the files (which is needed for a
couple of other features, like port contents, port provides, port space,
etc.)