Cool C libraries we could have on hackage server

[Maurí­cio]

 >> There are many libraries we probably would like to have
 >> bindings for, but we need to have them on hackage to do that.

> I really don't think that is true.
> 
> Just to pick one that I am aware of:
> 
>     http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsndfile

hsndfile actually carries the one file it needs (sndfile.h)
with itself. Linking problems are delegated to those using the
library, something I would not like to do in a few packages
where I do want to release the user from these problems (see
bindings-libusb, bindings-sqlite3).  It doesn't ensure much
compatibility between versions of the base library, although
I don't know libsnd enough to say if this is a problem to this
particular package.

>> What if we
>> generate a wish list of really trusted and important libraries
>> we would like to use, and then test if they build on hackage,
>> and install in /usr/local those that do?
> 
> Thats probably a really bad idea on Debian or Debian derived
> distributions, where Haskell bindings to these libraries should
> really link against the versions of the libraries installed by
> the package manager.

My impression was that the server was kept at an old version,
maybe for reliability issues, since I did 'apt-cache' and didn't
find libusb-1.0, only the old libusb-0.1, but I understand
nothing of debian or good practices on server management. I
just thought that if upgrading the server was an issue, let us
build packages outside its package management tool.

 > On Linux (probably true for Unix in general), Haskell bindings to
 > C libraries should use pkg-config in the build process to find the
 > location of the required libraries and headers.

Exactly! You need those libraries installed so that cabal accepts
building your pkg-config dependent package.  I do want to release
an installer with a set of libraries in my bindings-* packages
with pkg-config for Windows too.

Thanks for your comments,
Maurício