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?
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 -
are seen as a distraction the more we can automate this the better,
I've run into this trouble as well. And libraries will change... or
there will be libraries which are not updated etc..
I think another way would be having some automatism in fixing the most
obvious things.. Such as if package
On Friday 07 September 2007 09:57, Neil Davies wrote:
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
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
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
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 ?
Cheers
Neil
