The case for tweaking .cabal files of existing uploaded packages

[Duncan Coutts]

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