Skip to content

cabal2arch generates incomplete PKGBUILD for haskell-opengl #14

Closed
peti opened this Issue Nov 24, 2010 · 9 comments

3 participants

@peti
peti commented Nov 24, 2010

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.

@remyoudompheng

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).

@peti
peti commented Dec 24, 2010

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.

@remyoudompheng

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.

@peti
peti commented Dec 25, 2010

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?

@magthe
Arch Haskell member
magthe commented Jan 10, 2011

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.

@peti
peti commented Jan 10, 2011

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.

@magthe
Arch Haskell member
magthe commented Jan 10, 2011

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. :-(

@magthe
Arch Haskell member
magthe commented Jan 10, 2011

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.

@magthe
Arch Haskell member
magthe commented Jan 11, 2011

Depends on #22.

@peti peti closed this Nov 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.