That sounds good, it would however be interesting to find out what your criteria is (what you are looking for) and how your tool satisfies them.
A few things: - The documentation was so sparse, I thought it would be less effort to implement from scratch than try to figure out how the current system worked. In retrospect, I believe I was correct in this, not least because I'm not sufficiently expert at Haskell to efficiently figure out precisely what cabal2arch is doing. - cabal2arch treats all cabal dependencies as '=' and does not honor '<=' or '>=' which is a pain in the ass because it requires rebuilding everything when one package version changes. It's entirely likely there's a good reason for this; I didn't dig in because the idea offends me as it completely undermines the point of libraries in the first place. So I'm living on the edge with my implementation in this regard. - cabal2arch uses a hard-coded list of libraries provided by ghc, but this seems redundant due to the Arch ghc package's "provides" (which I assume came to be after cabal2arch was written). - I don't have a good alternate solution to the hard-coded list of library providers. I think maintaining this list is far more reasonable than the ghc-provides list, though, because it's specific to the intersection of Arch Linux and Haskell, whereas ghc provides is not. - I have probably made some erroneous assumptions here, but given the combination of lack of documentation, lack of response to the mailing list, and my substandard knowledge of Haskell, I figured the best way to solve my problem (ie, to install stuff from hackage I wanted to play with) was to roll my own. I am not upset at the aforementioned lacks; I enjoy the work and I enjoy the learning; please do not infer any angst from me here. As I said previously, I do plan to make my stuff generally available, but I haven't had time to add a baseline of polish so that people can actually use it relatively autonomously. ;) pete