[Haskell-cafe] Hackage bug? Autobuild failure on literate source with ignored code blocks.

[Duncan Coutts]

On Mon, 2009-09-28 at 12:53 -0700, John Millikin wrote:
> In that case, I'll update my code and the wiki to use an alternative code style.

Ok.

> On Mon, Sep 28, 2009 at 09:21, Duncan Coutts
> <duncan.coutts at googlemail.com> wrote:
> > Your local Cabal version is older than the one Hackage is using and that
> > older version lets haddock (ie ghc) do the pre-processing where as in
> > the current version Cabal does the unlitting before running haddock.
> > That explains the difference you observe.
> 
> Since Hackage is using an unstable development build of Cabal, I'd
> like to force it to use a released version to prevent such an issue
> from occurring again. I've added the following line to my .cabal file:
> 
> cabal-version: >= 1.6 && < 1.7
> 
> However, when testing with Cabal 1.7.3 (which is the version used by
> Hackage), I am warned that:
> 
> -------------
> Warning: dbus-core.cabal: This package requires Cabal version: >=1.6 && <1.7
> Distribution quality errors:
> This package requires Cabal version: >=1.6 && <1.7
> Note: the public hackage server would reject this package.
> -------------
> 
> Does this mean that it's impossible to require an earlier version of
> Cabal in Hackage-published packages? If so, the use of a development
> version of Cabal in the auto-build system seems unwise.

There's two separate issues. One is whether the package is readable by
the later Cabal versions and the other is if it can be built. The
hackage server itself must be able to handle the .cabal file. If
that .cabal file declares that it cannot be used with a later Cabal
version then we cannot do that, and we cannot accept that package on
hackage. We need to be able to use later versions of Cabal on hackage
than are in general use so that we can add new QA checks etc.

The auto-builder is a separate matter. It's widely acknowledged that
using a single builder is not a good idea. The new server will allow
there to be many build clients and they can run a variety of versions of
Cabal.

What we really want is to version the package spec separately from the
default build system. Upper bounds on the package spec make no sense
where as upper bounds on the build system version make some sense
sometimes.

Duncan