https://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489 .... this is almost identical to my problem. I am just trying to help others on this list who are using Ubuntu Linux to avoid my predicament!
I had that problem upgrading too.
I posted a workaround:
http://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489/comments/9
|What's going on: |-------------------------- |Every Haskell library gets registered with the Haskell compiler ghc. |The ghc-pkg program is used to do that. Packages get registered |(ghc-pkg register) when they're installed and unregistered (ghc-pkg |unregister) when they get uninstalled or upgraded. To be unregistered |they have to be registered in the first pace. |So what's gone wrong is that ghc itself has been upgraded before the |other libs (gtk2hs, mtl etc) were unregistered.When ghc gets upgraded |it includes an empty package database. So now when it comes time to |upgrade the other Haskell libs they are of course no longer registered |(because they were registered with the older version of the compiler |and not the new one). The uninstall script then fails because ghc-pkg |unregister fails, since the package is not registered. this sounds as if the uninstall simply needs an option deciding between uninstall-or-fail and achieve-uninstalled-state? but then again, uninstall should know from which compiler version/package database to uninstall, and uninstalling ghc should not disappear things without notifying other (un-)installation tools. i'll abuse this real-life opportunity to point once again at a serious flaw in the "throw-away installations" idea in common use for haskell compilers and libraries: there is no support for upgrading or cross-version consistency! throw-away installation: - if you install a library or a compiler version or tool, it puts itself in a separate place, free from interference with other libraries or compiler versions - usual practice then cleans away/forgets about the source for the installation, so the installation is not repeatable; it also forgets about the other dependencies that were used to build this installation (specific package or compiler versions needed to build this library/compiler/tool) - if you uninstall a library or a compiler version, it just removes itself (and even that isn't all that well supported, beyond unregistration..) there are so many ways this can go wrong that it is surprising that the real-life bugs have taken so long to show up.here are some examples (many of which have been discussed earlier, but have always been tracked as low priority/nice to have..): - if i update my ghc, i want to take all my libraries with me (especially since binary incompatibility means that i can't just reuse the existing installations..) - if i uninstall a version of ghc, i want to be reminded of which libraries are installed only for this ghc version (the libraries i'd lose by uninstalling, as opposed to libraries also installed for later ghc versions), and which installed tools were built using this ghc version (in case upgrading them still requires that old version..) - if i install a new library, i don't want version conflicts because an older, incompatible library version is in use by other packages - if i uninstall a library, i don't want dangling references to it in the package database - i don't want to have to remove anything explicitly, because that would mean bypassing the haskell installation managers - i would want to see a single haskell installation manager for each system, covering compiler versions as well, not to mention collaboration between all cabal/ghc-pkg versions currently installed; so that i can ask about all the package databases/compiler versions/packages; this might also help as a coordination point for upgrades - i would like to be able to determine, for each installed tool, library and compiler, which package and compiler versions were involved in building it, by querying that haskell installation manager - .. it just isn't sufficient not to interfere with existing stuff, it is important to be aware of relationships with existing stuff, and to adjust actions and practices accordingly (to guard against inconsistencies/disappearing dependencies, and to support upgrades/reproducable installations). perhaps the existing tickets in this direction could be given higher priorities, and the various groups and tools concerned with packaging could coordinate on this? claus