
Thinking on it more - surely there is enough information from the
failed compilations to suggest changes to the cabal files? Feed them
back to the developers?
My thoughts go this way - people like creating, that's why hackage is
beginning to grow. They don't tend to like the packaging issues - they
are seen as a distraction the more we can automate this the better,
the more quickly the libraries are going to get up to date.
As a community we are building a momentum here - let's not derail it
by a lack of attention to detail.
Neil
On 09/09/2007, Neil Davies
Ah,
this begins to answer my question: there isn't really a plan....
I would have thought that he first step is to be able to distinguish which of the hackage packages "compile" under 6.8 - some annotation to the hackage DB? Secondly, is there a dependency graph of the stuff on hackage anywhere? That would identify which order to change packages in (for example the cabal-install package is dependent on exactly one version of the HTTP library). We need to size the problem.
Nei
On 09/09/2007, Duncan Coutts
wrote: On Sat, 2007-09-08 at 14:50 +0100, Neil Mitchell wrote:
Hi Neil,
Given that GHC 6.8 is just around the corner and, given how it has re-organised the libraries so that the dependencies in many (most/all) the packages in the hackage DB are now not correct.
Is there a plan of how to get hackage DB up to speed with GHC 6.8 ?
I think whatever we go with will be deeply painful. Especially given the switch to Cabal configurations comes at the same time, rather than before.
Cabal 1.2 is out now and supports configurations and current ghc:
http://haskell.org/cabal/download.html
Duncan