[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
rebuilt.
> 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
operation.
> 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
priority.
Cheers,
Thomas
[1] http://hackage.haskell.org/platform/
More information about the Haskell-Cafe
mailing list