Our ports tree contains 565 Haskell ports at the moment. Only 51 of them
are executables (like pandoc or cgrep), while other 500 are just
LIB_DEPENDS of those 51. Haskell packages are obtained from Hackage [1], a
package database much like Python's PyPI or Perl's CPAN. There was a reason
to have all these Haskell library ports in tree - Hackage provide no
guarantee that packages it holds can work together. It was easy to get into
"dependency hell" situation, for instance. Due to this, our ports tree was
playing a role of a "known-to-be-working subset of Hackage". Thanks to
poudriere and our package builders we were sure that all hs-* ports do work
together and there are no dependency issues.
Then, the Stackage [2] appeared. Stackage provides lists of Haskell package
sets known to be working together for a given compiler version. It is
solving the same problem we are solving in ports.
The last lang/ghc upgrade took about a month for me, as I was fighting
through */hs-* ports failures. The maintaining burden is too high and has
no sense, because we are duplicating the work that Stackage does.
So, my idea is simple:
1. Remove all */hs-* ports that are just library dependencies to other
*/hs-* .
2. Except, probably, ones that need patching.
3. Convert remaining (executable) */hs-* ports to use Stackage as
dependency source.
There is a problem, though. Unlike Python or Perl, Haskell is a compiled
language. This means that if we compile 2 apps that has, say, 100 Haskell
library dependencies, we would have to compile these 100 packages twice.
These deps would be statically linked into 2 both apps. There would be no
build-time sharing now. I think, when building straight from ports some
caching could be arranged, but I doubt it will work out for poudriere.
What do you all think of this? What cource of action should we take?
[1]: http://hackage.haskell.org/
[2]: http://stackage.org/
