Hi Rémy,
I accidentally pushed that change to the provides list with another commit, but I wanted to ask the mailing-list about it before pushing it (it caused PKGBUILD to no longer have redundant haskell-cabal and other dependencies).
yes, there are both advantages and disadvantages to this change. Now that PKGBUILDs don't list the dependencies provided by GHC anymore, we no longer rely on 'provides', and any ArchLinux package manager ought to be able to handle our builds just fine. This is good, of course. On the other hand, our PKGBUILDs are now implicitly designed to be used by GHC. If there were a new production-ready Haskell compiler to emerge that would provide a different set of standard libraries, then those PKGBUILD files would no longer work correctly because of those implicit dependencies. I feel that's a theoretical problem, though, and we can worry about that later when a new major compiler actually appears, which is probably not going to happen any time soon.
I saw that you added options to personalize names of generated packages: do you plan to support packaging multiple versions of a single library?
Yes, my PKGLIST now contains both package names from ArchLinux and Cabal: http://github.com/peti/arch-haskell/blob/master/PKGLIST. This allows us to include multiple versions of the same package in the distribution, i.e. like this: # # ArchLinx pkgname Cabal pkgname Version Release # haskell-pandoc1 pandoc 1.6 1 haskell-pandoc pandoc 2.0 1 I'm also planning to augment PKGLIST with a set of options that are to be applied in the conversion, for example: # # ArchLinx pkgname Cabal pkgname Version Release Flags # haskell-pandoc pandoc 1.6 1 haskell-pandoc-full pandoc 1.6 1 -fhighlighting -fciteproc I'm not quite there yet, and this change is going to require further genereralization of the archhaskell library API, but IMHO that feature would be worthwile to have. Take care Peter