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

Thomas DuBuisson thomas.dubuisson at gmail.com
Sat Sep 11 14:56:35 EDT 2010

> - when recompiling a package with ABI changes, does cabal always
> update dependent packages?

If Foo depends on Bar and there is a new version of Foo that specifies
a newer version of Bar then yes, the newer library being depended on
will be build too (out of necessity).

OTOH, if you are building a new version of a package on which others
depend it won't build all the others.  Ex: build a new "containers"
package doesn't cause any of the ~1400 packages depending on it to be

> It seems "not always" - it didn't update
> itself, nor refuse the breaking upgrade,

I don't really know what "it" is.  Something to do with recompiling
Cabal and cabal-install I take it, but I'll refrain from comment
seeing as I don't understand what you're doing.

> - is there a "specification" of which are the "core" packages?

Are there packages on which the community standardizes?  That's the
goal of Haskell-Platform [1], but I don't place any special value in a
package being in HP yet - I just work with whatever package on Hackage
fills my need and am under the impression this is most peoples mode of

> While package
> removal is not supported through cabal, it is sometimes needed

Why?  What I see is a need for users to understand ghc-pkg (or
whatever package management tool exists for their Haskell compiler).
Should "cabal uninstall" provide a unified interface to some number of
Haskell compiler packaging systems?  It could but doesn't seem like a


[1] http://hackage.haskell.org/platform/

More information about the Haskell-Cafe mailing list