For now, we just edit .cabal files when transporting code between GHC versions...
Just for information, the HaXml darcs repo has recently adopted the solution of containing two .cabal files, one for ghc-6.6.x, and the other for the split-base packages (>=ghc-6.7). The only difference is the build-depends line, which is now as follows:
build-depends: base, haskell98, polyparse, pretty, fps
But if you have collected the earlier release HaXml-1.13.2 from hackage, then you can omit both 'polyparse' and 'fps' dependencies. ('fps' will shortly be changing to 'bytestring' in any case...)
would it be possible to put more emphasis on continuity in haskell (just as there should be an emphasis on portability;-)? when changing language, tools, or libraries in a way that breaks existing programs, deprecating the old api for one version before removing it is rarely sufficient, and leads to breakage rather than hackage.. it would be nice if anyone thinking of breaking a public api would spend some thought on code transitions. be it by providing compatibility adapters, or code transformations, or whatever. users should not be so accepting of breaking changes, either. yes, you may be able to work around the issues, but what good are package managers if they only work with workarounds? in this particular case, the rest-base simply doesn't do what base did, so it shouldn't be named base. instead, perhaps there should be a virtual base package that only tracks the dependencies needed to support the old base? similarly for the now-its-in-now-it-isnt fps/bytestring. :-) claus