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 ?
Ian, GHC HQ, can you elaborate on what the plan is on fixing the hackage libraries for ghc 6.8 -- should everyone be springing into action to update .cabal files and fix api changes? -- Don
On Sun, 2007-09-23 at 18:02 -0700, Don Stewart wrote:
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 ?
Ian, GHC HQ, can you elaborate on what the plan is on fixing the hackage libraries for ghc 6.8 -- should everyone be springing into action to update .cabal files and fix api changes?
The problem is that Cabal-1.2 is not backwards compatible wrt. the API for Setup.[l]hs. In most cases this can be fixed by using a trivial Setup.hs and use configurations instead, in which case you'll again depend on Cabal-1.2. In a soon-to-be-fixed variant of cabal-install this will simply imply having Cabal-1.2 as a dependency (and you can still keep older versions of Cabal around if you like). I agree this solution is not nice at all, but people seem to say that this is only a temporary solution. I'm not sure I agree. One solution I can think of to avoid having to use an either/or-approach: Use versioned .cabal and setup files. This way a package that currently builds with Cabal 1.1.6.x will work, and new features will be available if you explicitly compile using a Setup file that implicitly requires Cabal >= 1.2. Basically, if you have Cabal < 1.2 installed you'd do the normal 3 steps, and if you have Cabal >= 1.2 installed you use runhaskell Setup2.lhs configure and provide a Foo.cabal2 file. This could be automated by cabal-install, of course. This is not a pretty solution and also has the problem of incorrectly dealing with changes to the base interface. This, IMO, is due to keeping the name 'base' instead of opting to clarify the incompatibilities by choosing "base2". The second alternative is to allow a shortcut in .cabal files to specify dependencies: base 1 === base >= 1 && < 2 ("base-1" doesn't work because '-' is considered a valid character in package names.) / Thomas
In message <1190644931.18359.22.camel@intothevoid> Thomas Schilling
On Sun, 2007-09-23 at 18:02 -0700, Don Stewart wrote:
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 ?
Ian, GHC HQ, can you elaborate on what the plan is on fixing the hackage libraries for ghc 6.8 -- should everyone be springing into action to update .cabal files and fix api changes?
The problem is that Cabal-1.2 is not backwards compatible wrt. the API for Setup.[l]hs. In most cases this can be fixed by using a trivial Setup.hs and use configurations instead, in which case you'll again depend on Cabal-1.2.
Of course Cabal-1.2 works perfectly well with all versions of GHC (6.2 and later) so this is ok. For example, people using GHC-6.6.x can add Cabal-1.2 (keeping their previous version of Cabal library as well). So it's perfectly possible to make a package support many versions of GHC (and other Haskell impls), what is harder is making it support many versions of Cabal. In summary: supporting both GHC-6.6 and 6.8 "out of the box" is hard (unless your package is really very simple). Supporting GHC-6.6 + Cabal-1.2 and GHC-6.8 "out of the box" is easy. Duncan
On Sun, Sep 23, 2007 at 06:02:13PM -0700, Don Stewart wrote:
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 ?
Ian, GHC HQ, can you elaborate on what the plan is on fixing the hackage libraries for ghc 6.8 -- should everyone be springing into action to update .cabal files and fix api changes?
I'm a bit confused about the version numbering for the boot libraries. The versions bundled with various versions of GHC are: ghc-6.6: base-2.0 template-haskell-2.0 unix-1.0 ghc-6.6.1: base-2.1.1 template-haskell-2.1 unix-2.1 ghc-6.8 RC: base-2.1 template-haskell-0.1 unix-2.0 What versions are planned for the release?
On Sep 25, 2007, at 10:38 , Ross Paterson wrote:
On Sun, Sep 23, 2007 at 06:02:13PM -0700, Don Stewart wrote:
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 ?
Ian, GHC HQ, can you elaborate on what the plan is on fixing the hackage libraries for ghc 6.8 -- should everyone be springing into action to update .cabal files and fix api changes?
I'm a bit confused about the version numbering for the boot libraries. The versions bundled with various versions of GHC are:
ghc-6.6: base-2.0 template-haskell-2.0 unix-1.0 ghc-6.6.1: base-2.1.1 template-haskell-2.1 unix-2.1 ghc-6.8 RC: base-2.1 template-haskell-0.1 unix-2.0
What versions are planned for the release?
This seems quite broken. It makes writing Cabal configurations messy. base <= 2.0 and == 2.1.1 are the monolithic base. base == 2.1 (and presumably >= 2.2) are the split up base. Add to this that bytestring was in base == 2.0 (not <=2.0) and in == 2.1.1. Is there any reason not to bump the base that comes with GHC 6.8 to base-2.2? /Björn
bringert:
On Sep 25, 2007, at 10:38 , Ross Paterson wrote:
On Sun, Sep 23, 2007 at 06:02:13PM -0700, Don Stewart wrote:
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 ?
Ian, GHC HQ, can you elaborate on what the plan is on fixing the hackage libraries for ghc 6.8 -- should everyone be springing into action to update .cabal files and fix api changes?
I'm a bit confused about the version numbering for the boot libraries. The versions bundled with various versions of GHC are:
ghc-6.6: base-2.0 template-haskell-2.0 unix-1.0 ghc-6.6.1: base-2.1.1 template-haskell-2.1 unix-2.1 ghc-6.8 RC: base-2.1 template-haskell-0.1 unix-2.0
What versions are planned for the release?
This seems quite broken. It makes writing Cabal configurations messy. base <= 2.0 and == 2.1.1 are the monolithic base. base == 2.1 (and presumably >= 2.2) are the split up base. Add to this that bytestring was in base == 2.0 (not <=2.0) and in == 2.1.1.
Is there any reason not to bump the base that comes with GHC 6.8 to base-2.2?
or 3.0
On Mon, Oct 08, 2007 at 11:10:02PM +0200, Bjorn Bringert wrote:
On Sep 25, 2007, at 10:38 , Ross Paterson wrote:
I'm a bit confused about the version numbering for the boot libraries. The versions bundled with various versions of GHC are:
ghc-6.6: base-2.0 template-haskell-2.0 unix-1.0 ghc-6.6.1: base-2.1.1 template-haskell-2.1 unix-2.1 ghc-6.8 RC: base-2.1 template-haskell-0.1 unix-2.0
What versions are planned for the release?
This seems quite broken. It makes writing Cabal configurations messy. base <= 2.0 and == 2.1.1 are the monolithic base. base == 2.1 (and presumably >= 2.2) are the split up base. Add to this that bytestring was in base == 2.0 (not <=2.0) and in == 2.1.1.
Is there any reason not to bump the base that comes with GHC 6.8 to base-2.2?
To allow specifying conservative dependencies, it is also necessary to specify for each boot package the range of version numbers that can ship with GHC 6.8.x (all guaranteed to have the same interface). And, when GHC 6.8.1 is released, to advance the version numbers of these packages in the HEAD beyond these ranges.
participants (5)
-
Bjorn Bringert -
Don Stewart -
Duncan Coutts -
Ross Paterson -
Thomas Schilling