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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
