So here's an example where despite our best efforts to get backwards compatibility, a package has been uploaded which breaks the parser of cabal-install-0.6.x. That's the stable series which goes along with ghc-6.10, which many users are still using. We only just recently marked version 0.8.x as recommended. The hellage package has the following highlights: Name: hellage ... Cabal-version: >= 1.4 ... Executable hellage-genmeta Build-Depends: base (>= 4.2) The problem is that the version range syntax uses a feature from Cabal-1.8, but since the cabal-version is marked as 1.4, then this breaks for Cabal 1.4 and 1.6. In Cabal-1.8 we generalised the version range syntax to allow arbitrary && || clauses with ()'s. We added a check so that packages using the extended syntax would be detected and required to declare that they need 1.8 or later. The above example slipped past our check because we do the check at the AST level and the parser strips off the ()'s. Currently anyone doing "cabal list" or any install command that depends on this package will fail: http://twitter.com/ranha/status/13954962378 It's in Japanese, but you get the idea. So the suggestion is that in addition to improving the check, we simply alter the .cabal file in the archive (but not the tarball) to have the corrected syntax. When the index is next updated this should unbreak old clients. Of course they will still not be able to install this specific package, but at least they'll get a sensible error message. (As an orthogonal issue, it would obviously be good to make cabal-install more robust in the way in which it handles unparsable packages in the index.) Note that this is the thin edge of the wedge, and I would like to go further in future. In the new hackage server I would like to make it possible to edit -- to a highly limited degree -- the .cabal files of existing packages. This would mainly be for meta-data (descriptions, URLs, etc) but more interestingly to adjust version constraints if they are found to be too lax or too tight. It would also mean adjusting cabal-install so that it uses the .cabal file from the index in preference to the one in the tarball when building a package. Duncan