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/