In message <1759568487.20070925192337@gmail.com> Bulat Ziganshin
Hello Duncan,
Tuesday, September 25, 2007, 4:46:09 PM, you wrote:
Don was suggesting we start a wiki page with advice to package maintainers on what updates are common for the transition to ghc-6.8 and cabal-1.2. This is a
i think that generally requirement to update libraries to meet 6.8 reqirements isn't a good idea. can we provide full support of old packages in 6.8, for example by inclusion both new and old Cabal versions in default installation?
That would not help a great deal. One of the main reasons many existing package will not build with ghc-6.8 is due to the split up of the base library. The new features in Cabal-1.2 help with this to enable a package to build with both old and new versions of ghc. It would be possible to update the Cabal-1.1.6 branch to build with ghc-6.8 (though it could then not build with ghc-6.6 precisely because the older version of Cabal does not include the new configurations feature which enables such flexability.) I would also not make anything work automatically since how does one tell which version of the Cabal library to use? We currently do not have the information or infrastructure to track this, though I agree that it's something we should think about carefully for future transitions. We currently can specify a Cabal version range in a .cabal file that the package can work with. That's ok for specifying minimum versions but not for maximum ones since package authors do not know when the Cabal API changes. That needs proper API versioning. With that inplace it's easy for cabal-setup to do the right thing, just as it does currently if a .cabal file specifies a Cabal version range - it compiles the Setup.hs with the right version of the Cabal lib (if it's installed). Something we should encourage in this transition which will make things less disruptive in future is to get people to use "build-type: Simple" in their .cabal files and not use Setup.hs files at all. The Cabal library api is a good deal less stable that the .cabal file format and this is the weak point since currently we require the Setup.hs script to be able to do anything. And when it does not compile there is no friendly error message like there is when we deprecate old fields in the .cabal file format. Duncan