it is almost as if everything feels free these days to evolve in non- backwards-compatible ways, following the motto "what do i care for my apis of yesterday?".
i picked cabal as an easily demonstrated *example*, not as the only culprit. for instance, if base gets split up into smaller parts, and the *remainder* gets called base, even though it no longer provides the same functionality as the old base package, that is not cabal's fault. i'm not interested in blame-games, and my concern is with a general trend rather than any particular tool or library. as far as _stability only_ is concerned, there is nothing wrong with *adding* features or with *cleaning up* existing code; the problems come when *externally used* features are *removed* or *new dependencies* are introduced. lets have a look at that base package example, for a change: if the remainder had been called base-core and base had become a proxy package that provides no functionality other than recording the new dependencies needed to get hold of the old functionality, by depending on the spin-off packages, then there wouldn't have been any externally visible changes to base, old code depending on base would still work as long as base was installed, and new code could bypass base, using base-core and other spin-off packages directly. same for cabal: if it learns to do new things, do old things in nicer ways, or interpret more information, *that should not affect any old code*. if old code breaks, that means that old information is no longer accepted, old dependencies are no longer sufficient, or old functionality is no longer provided.
This is the development version, so you can't really expect it to be stable at all.
i'm not concerned with the development versions of cabal (and again:none of this is specific to cabal), which i never expect to see. i'm concerned with the versions of cabal that are in active use, in ghc head, hackage or elsewhere. if a version of some centrally important software (be it library or tool) is used, then that version's functionality/api should be supported for as long as practical. compatibility packages and automatic translators are not ideal, but better than nothing; simply abandoning old clients is the worst situation. ideally, new versions of such software should still support old clients, while warning about uses of deprecated functionality (somehow, deprecation warnings have come to mean "it will be gone in the next version", when it used to mean "it will not be here indefinitely").
So, could you please exclude Cabal (and stay with me when I say we hope to have things stable by the next ghc release), re-evaluate the situation excluding anything related to Cabal issues (ie, setup.lhs errors), and see if your issue still exists?
yes, it does. it just turns up in cabal so often because (a) there's a lot of development there (which is great!-), (b) cabal is aiming to become central to all haskell development (which is rather a huge burden of responsibility). the more cabal succeeds, the more maintenance issues will be related to cabal, and the more cabal is used, the higher the standards for backwards-compatibility it should aspire to achieve. </soapbox> :-) claus