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.) From reading http://www.haskell.org/ghc/docs/7.0.1/html/Cabal/builders.html it seems we're already using most of those features short of calling cabal-install directly. I think the best solution would be to attempt automating as much of the package creation process as possible and to reduce the number of packages that can be used alternatively (e.g., don't keep hs-text _and_ hs-platform-text). -- Clemens Lang _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
