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

[Paolo G. Giarrusso]

Hi all,

I would like to share a new very cool result given by the current
Cabal: if packages FOO, BAR and FOOBAR exist, such that FOO depends on
BAR which depends on FOOBAR, and all three are installed, you just
can't safely upgrade FOOBAR. When the same version of BAR is ever
recompiled against the new FOOBAR, its ABI might change and FOO _will_
thus break if you're not very lucky.
Call it the No Upgrade Theorem, if you want.
Note that upgrades of FOO and BAR can still be safe: the key
hypothesis is a dependency chain of 3 packages, and the thesis is that
the deepest of the three ones in the chain (FOOBAR in the above
example) can't be upgraded safely.

Not that it's necessarily Cabal's "fault", IMHO. Given this kind of
cross-module inlining, proper dependency handling (which includes what
we discussed) seems insanely complicated to get right. Of course,
Cabal can be fixed, but I would call that a major achievement.

On Sep 13, 12:53 am, Brandon S Allbery KF8NH <allb... at ece.cmu.edu>
wrote:
> On 9/11/10 15:43 , Daniel Fischer wrote:

> > On Saturday 11 September 2010 20:38:21, Paolo Giarrusso wrote:
> >> - is there a "specification" of which are the "core" packages?

> > "core" as in *do not update*?
> > Basically, what comes with GHC shouldn't be updated.
> > Though I heard updating Cabal was okay.

> Some consistency would be nice; IIRC GHC refers to them as "boot libraries".

"Boot libraries" clearly refers to GHC bootstrapping. But with a
statically linked GHC (like on my system at least, and maybe
everywhere), GHC dependencies are irrelevant, only "transitive
dependency closure of (those used by Cabal + those used by any
programs (base, ghc-prim, rts, integer...))" are relevant. Which
includes an additional package, "pretty", and excludes many other.

To verify this theory, I upgraded "bytestring" (on which GHC but not
Cabal depend), and I can still configure+build+copy packages. But of
course, bytestring fulfills the hypothesis of the above theorem, so
installing a package with enough dependencies might trigger actual
breakage. That's however not because ghc depends on bytestring.

Only Cabal is special, because if you break that you can't recompile
anything any more, and because recompiling Cabal dependencies and
Cabal takes special effort (as said elsewhere). That's why "core
packages" should include just cabal (recursive) deps.

Fixing the "No Upgrade Theorem" is easier, just recompile more stuff
and/or give more warnings.
--
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/