[Haskell-cafe] Re: A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies

[Paolo G. Giarrusso]

On Sep 13, 1:52 pm, Ross Paterson <r... at soi.city.ac.uk> wrote:
> On Sat, Sep 11, 2010 at 12:17:27PM -0700, Jason Dagit wrote:
> > "To avoid this problem in the future, avoid upgrading core packages.
> > The latest version of cabal-install has disabled the upgrade command
> > to make it a bit harder for people to break their systems in this
> > way."

> It's not always possible.  In particular, random-1.0.0.2 (shipped with
> GHC 6.12.*) depends on the time package, of which more recent versions
> have been released.  That can trigger rebuilding of random-1.0.0.2,
> and thus haskell98-1.0.1.1.

My case was similar, old-locale had been upgraded. And currently,
haskell98 would not necessarily be rebuilt automatically - it would
just break.
The point is that time should _not_ be upgradeable with the current
system, for the same reason as "cabal upgrade" is disabled. The
alternative is to allow Cabal to rebuild itself _and_ GHC (and
everything) safely.

BTW, I just realized that thanks to static linking, the ghc and cabal
binaries should never stop working - only using those libraries for
building packages could break. If you always upgrade locally, you can
always remove packages from the user DB as I did.

> It might help if the release of random with GHC 7.0 had a tight dependency
> on the version of the time package shipped with it.  Maybe all the core
> packages need tight dependencies.

If you mean it as a hack for cabal's brokenness, it could be OK, but
otherwise than that, I believe it's a bad idea. GHC itself does not
depend on any specific package; it's the compiled GHC package which
has a tight dependency. So I don't like the concept.
Furthermore, if a GHC release (whichever it is) had a tight
dependency, that would be annoying for when you want to compile that
release against different libraries - if that is supposed to work.

But actually, on my system I can't see ghc in cabal's DB; I can see
that in the ghc-pkg database for binaries, but there all dependencies
are tight, probably because they are dependencies among installed
packages.

Have a look:
$ cabal info QuickCheck
[...]
    Dependencies:  mtl -any, base >=4 && <5, random -any, base >=3 &&
<4,
                   random -any, base <3, ghc -any, extensible-
exceptions -any
$ ghc-pkg describe QuickCheck | grep depends
depends: base-3.0.3.1 random-1.0.0.1

Best regards
--
Paolo Giarrusso, PhD student
http://www.informatik.uni-marburg.de/~pgiarrusso/