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

On Sat, Sep 11, 2010 at 21:17, Jason Dagit wrote:

On Sat, Sep 11, 2010 at 11:56 AM, Thomas DuBuisson 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/