Hackage and GHC 6.8 - Haskell-Cafe - Haskell.org

newer
Help understanding type error

Hackage and GHC 6.8

older
((a -> b) -> c) -> (a -> m b) -> m...

Neil Davies

7 Sep 2007 7 Sep '07

7:57 a.m.

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

Reply

Sign in to reply online Use email software

Show replies by date

Sven Panne

8 Sep 8 Sep

1:44 p.m.

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 speed with GHC 6.8 ?

Given all those changes in the library structure and Cabal, naming the next GHC release "7.x" (probably 7.0.1, if I understand the current naming policy correctly) would be better IMHO, giving everybody a clear hint about portability issues. (even if those issues are "only" import changes, *.cabal/Setup.hs changes and various minor library API changes) But it's too late for such discussions, 6.8.1 has already been branched... Cheers, S.

Reply

Sign in to reply online Use email software

Neil Mitchell

1:50 p.m.

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. However, remember this is a one of set of pain, which will hopefully never be repeated. In the absence of anyone else doing anything, I'll probably give it a month or two, then upgrade all my packages on hackage. Thanks Neil

Reply

Sign in to reply online Use email software

Duncan Coutts

9 Sep 9 Sep

1:31 a.m.

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

Reply

Sign in to reply online Use email software

Neil Davies

7:24 a.m.

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

Reply

Sign in to reply online Use email software

Neil Davies

7:36 a.m.

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 wrote:

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

Reply

Sign in to reply online Use email software

Marc Weber

2:17 p.m.

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 X does no longer export module y look in the package db which package does and add this instead.. I don't konw how well this will work in practise.. But I'll try when having some time to do so.. Marc

Reply

Sign in to reply online Use email software

6512

Age (days ago)

6514

Last active (days ago)

Download

6 comments

5 participants

tags

participants (5)

Duncan Coutts
Marc Weber
Neil Davies
Neil Mitchell
Sven Panne