Exactly. Of course reports about problems and suggestions for improvements are always welcome, but I wouldn't mind reports about working platforms, too. Currently I don't have a clear picture which package works where...
I've installed OpenGL-2.2.1.1 and GLUT-2.1.1.2 with ghc-6.11.20090320, on windows xp, using cygwin&mingw, though I had to add a configure option:-( cabal install opengl --configure-option="--host=i386-unknown-mingw32" cabal install glut --configure-option="--host=i386-unknown-mingw32" (that is with "GLUT for Win32 version 3.7.3 as of October 2nd 2000").
This raises a point which is a bit unclear, at least for me: Where do users of the HP report a bug? It can be a bit tricky to decide if it's only a packaging bug, which I can't fix, or a real bug in the OpenGL/GLUT binding. Has this been discussed in the "HP inner circle"?
I'm a square, I belong to no circles!-) You'd need to ask on the HP list. But OpenGL/GLUT don't have a trac instance yet, and I've had little success in the past with cc-ing you on issue reports, so having all OpenGL/GLUT reports on the HP trac, in a OpenGL/GLUT component, wouldn't be a bad start, would it? Of course, you could add an OpenGL/GLUT trac on trac.haskell.org: http://community.haskell.org/ and then there'd be the question of which trac to use for what.. I'd expect bugs to be reported on either trac, then forwarded to the other one if necessary. The same as currently happens with ghc vs hackage/cabal vs haddock tickets.
I really, really hope that the minor HP release will allow feature additions where the major version number of the package stays the same. Everything else would bring down distribution of much-wanted features to a crawl and force people to install the packages by hand once again. But again, I don't have a clue what the HP people decided about this...
OpenGL/GLUT is a special case, because it was dropped from extralibs so long before HP had code associated with it. If not for that gap, the time-based HP releases might work (HP is about easy access to stable reference sets of packages, not about the latest versions). So I agree that there should be an exception to the general HP policies to get OpenGL/GLUT off to a good start again. But that's just me (I also argued against dropping OpenGL/GLUT from extralibs) - if there are only one or two people affected, there's no reason for action, and if there are more people affected, they should make themselves heard in the appropriate forums. On windows, OpenGL/GLUT does seem to install fairly easily using cabal, provided one has msys or cygwin, and glut.. It can only be easier on other systems, right?-) The problem is that the Haskell binding would allow people to use OpenGL/GLUT who do not usually dabble in C or msys, so having a binary tarball (or an uptodate HP installer) helps a lot. Not to mention users who can't install stuff, let alone msys, on the machines they want to use for OpenGL/GLUT hacking. Unfortunately, with OpenGL/GLUT no longer in extralibs, the existing machinery for daily binary snapshots of the latest package version (via ghc snapshots) is gone, and the hackage server probably can't build windows binaries. But someone else could set up a weekly build of OpenGL/GLUT on a spare windows desktop. Or the situation with msys or cygwin installation to support cabal install could be cleaned up to get rid of this issue once and for all.. The question is how many potential OpenGL/GLUT users are still affected by this, ie, not served by 'cabal install'?
Windows installer RC (does *not* include glut32.dll): http://projects.haskell.org/pipermail/haskell-platform/2009-May/000147.html
Personally I hope this will get fixed for the initial release, otherwise the HP will be only semi-functional out-of-the-box.
If anyone else wants to chime in, the haskell platform mailing list is the place to go. Claus