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