patch applied (packages/regex-base): Make setup scriptcompileagain after recent Cabal changes

[Ross Paterson]

On Sat, Sep 01, 2007 at 05:20:23PM +0100, Claus Reinke wrote:
> 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.

That wouldn't work, as packages can't re-export modules.  And even if
they could, this method would be very awkward.  This is about the third
time that base has shrunk, and hopefully not the last.  This protocol
would leave us with some rather awkward names.

Fortunately the damage is limited.  Module interfaces have largely
observed the kind of stability you're asking for, it's just which packages
contain those modules.  So the needed change is confined to one line of
the .cabal file.  It's a pain to support different versions, but Thomas
has just extended Cabal to make this much easier.

> 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.

Cabal really is a special case.  The API is still much too immature to
stabilize, which is why it's handled differently from the other libraries.
It was never claimed to be stable.  However a package that uses a
boilerplate Setup.hs (as 90% of the packages on Hackage do) needs only
backwards compatibility of the .cabal format, and that has been carefully
preserved.  With the recent improvements to Cabal, fewer packages will
need the tailored setup scripts that are so fragile.  To impose extra
constraints on the Cabal API at this point would make it harder to make
the wholesale cleanups and enhancements needed to benefit all the other
packages, such as Thomas's recent implementation of configurations.

There is a common issue, but it's the "birthpangs of a new package
system".  Pouring concrete over Cabal in its current state won't help.