[Haskell-cafe] Ubuntu and ghc

[Claus Reinke]

>> 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