On Tue, May 30, 2006 at 12:05:44PM -0700, Jeremy Shaw wrote:
I have a first cut of a template for cabalizing and debianizing haskell libraries.
I haven't had a good look, but I note you use dh_haskell. Personally I don't see the attraction of dh_haskell over update-haskell-control. The latter can be used to keep build-deps in sync as well as deps (and the fact that dh_haskell looks like it still incorrectly generates deps like ghc6 (<< 6.4.1-999) at least 7 months after I first talked about it with John doesn't help endear it to me either; correct info is in /usr/lib/haskell-utils/${impl}_vars and can be augmented if wanted) and will hopefully in the future make it easy to also generate build-deps and deps for Haskell libraries by parsing the .cabal file.
If policy is changed so that we don't want to strictly depend on compiler/library versions then using both might make sense, one to get Haskell implementation arch info and Haskell libraries needed for the build-deps and the other to generate the appropriate deps at build-time.
My personal opinion is that policy is right, however, as we will want to make sure everything is built against up-to-date libraries/compilers everywhere (both for bug-fixing reasons and so migrations to testing can happen), and with the low version turnover and flat dependency tree we have I think this way will be less effort overall.
If I'm missing some other way in which dh_haskell would make my life easier, please do enlighten me :-)
Thanks Ian