The OpenGL package depends on 'mesa'. Unfortunately, the Cabal file doesn't specify that fact anywhere, so cabal2arch doesn't know about it. Consequently, the generated PKGBUILD lacks the dependency and fails to install.
What is the error ? the OpenGLRaw explicitly depends on the library "GL", and the translation should be done. I guess there is a lowercase/uppercase issue in data/library-providers.txt (from the archlinux module).
Well, the error is that "haskell-opengl" should depend on "mesa", but doesn't. Just re-generate the PKGBUILD to see how the result differs from the version we have in the habs repository. That version -- which builds -- was hand-edited to include the 'mesa' package in depends.
cabal2arch generates correct dependencies for the OpenGLRaw package (maybe it should be mesa instead of libgl, I'm not sure). The .cabal file for OpenGL does not specify the dependency anywhere.
It is true that the cabal file for OpenGL doesn't specify the dependency on 'mesa'. However, the generated package "haskell-opengl" will not build without 'mesa'. So what do we do about it?
Isn't this clearly a bug in the upstream CABAL file?
I don't know how much hope there is of getting it fixed for the version on OpenGL we are interested in though.
Yes, it is a bug in the upstream cabal file. That cabal file, however, happens to be a part of Haskell Platform! So what are we supposed to do? If we want to conform to HP, then we cannot update that version, which means that we have to deal with the broken Cabal file in some way. If the new HP standard comes out, this problem is probably going to go away. But at the same time, if HP standardized a broken Cabal file once, who says that this is not going to happen again? If we can't think of anything, then we'll have to live with hand-editing that PKGBUILD. That approach is not pretty, though, and it's error prone.
We should bring this up in the mailing list for haskell-platform first of all. If we want to deal with this in our own tools I suppose we'll need yet another mapping file. :-(
I had a closer look at the package and it seems that upstream decided to use configure-time check, in configure.ac, rather than using the CABAL property. I suspect that there are good reasons for doing this sometimes, even though CABAL most likely supports almost everything a developer would ever need.
I found a more recent example of this, hogre (version 0.1.1). It checked for an executable at configuration time, which of course also threw cabal2arch completely.
What I think these examples tell us is that we need to come up with some mapping of $_hkgname to a list of extra dependencies, in order to cover incomplete CABAL files.
Depends on #22.