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

[Paolo Giarrusso]

On Sat, Sep 11, 2010 at 21:17, Jason Dagit <dagit at codersbase.com> wrote:
> On Sat, Sep 11, 2010 at 11:56 AM, Thomas DuBuisson
> <thomas.dubuisson at gmail.com> wrote:
>
>>> - is there a "specification" of which are the "core" packages?

> From the FAQ linked by Paolo:
>
> http://www.haskell.org/cabal/FAQ.html#dependencies-conflict
>
> "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."
>
> I think that's what Paolo meant by "core" package.  Sadly the FAQ
> doesn't say what core means.  Nor is that page user editable.  I think
> "core" here must refer to packages that ghc is linked to.  For
> example, the process package in the example on the FAQ.

You are mostly correct, thanks for understanding. As said my case,
"core package" extends to packages cabal is linked to. Still, cabal
should know and protect them.
"core package" is also used in the output of "cabal upgrade" (which in
my release, 0.8.2 with Cabal 1.8.0.6, is disabled):

Below is the list of packages that it would have tried to upgrade. You can use
the 'install' command to install the ones you want. Note that it is generally
not recommended to upgrade core packages.

It is noteworthy that "cabal install --help" has no such warning.

Anyway, package manager Gentoo and *BSDs can upgrade everything while
the system is running. It would be nice to do the same here, including
"cabal install ghc", but "if you want, you can fix it" would be an
appropriate response - I kind-of know I won't get to do that, likely,
at least not while starting my PhD.

> I actually had this problem last weekend and I make a habit of never
> running 'cabal upgrade' and never installing things globally.  Yet
> some how on my system a package that ghc was built with did get
> upgraded and installed in my user package db.  It was causing various
> things to fail to configure.  If I recall correctly it was the
> directory package, but I'll use FOO as a place holder.  I used the
> suggested command line:
> ghc-pkg unregister --user FOO-X

> ghc-pkg said it was ignoring the command because it would break
> packages. So then I tried adding --force.   At that point, ghc-pkg
> still said it was ignoring me and that I should use --force.  This was
> on ghc-6.12.1.  I tried it one more time with the --force option then
> ran ghc-pkg list FOO, and all instances of the FOO package were gone.
> At that point I could no longer configure any packages needing FOO.
> In the end I had to reinstall ghc so I took it as a chance to upgrade
> to 6.12.3.

Hmm... how comes that your global DB was user-writable? Luckily, it's
owned by root here.
Anyway, I consider most of the debugging I did quite challenging for
non-Unix-guys, and reinstalling from scratch would have been surely
faster.
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/