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...@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/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
