Re: No ghc-pkg unregister call on upgrade?
On Tue, Sep 22, 2009 at 11:50:15AM +0200, Joachim Breitner wrote:
> Kaol once thought about registering packages based on triggers, similar
> to how the documentation is registered at the moment. I very much like
> this idea, as it would move complexity away from the (many) library
> packages, as it would get rid of maintainer scripts! Kaol, is this still
> your plan for ghc-6.12?
Maybe. I haven't thought about this for a time and don't have in
fresh memory how ghc-pkg works. I'll try to recap the situation a
bit, about what's needed.
One issue was preserving local changes. It's a reasonable local
configuration change to have a package installed but hidden via
ghc-pkg. Preserving those changes would take a bit of work. One
possible way about it would be to have "dpkg-reconfigure ghc6" offer a
debconf dialog about which packages to hide or show. Maybe all that
it takes is to just query the Cabal registry and see what was hidden
in a previous version. There's the extra kink in this that by the
time any trigger in ghc6 gets run, all files in the old library
version have been removed already. Nothing insurmountable, it just
means that the last trigger run needs to leave something behind about
this.
The most straightforward way of writing a Cabal package registering
trigger is to just overwrite the old registry. Even if this would
remember any hidden packages' settings, then there's the question of
what to do about locally installed Cabal packages. People are likely
to install those as root and the trigger needs to not discard those
even if they didn't enter there via dpkg. One option is to use
another file as Debian haskell libraries' registry. Cabal already has
support for using a registry split into multiple files.
I'll review if I could make this work smoothly along with ghc 6.12.
Someone else is welcome to implement this, too. The natural place for
the trigger would be in ghc6 itself.
Reply to: