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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
