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