On Sun, Sep 27, 2009 at 11:37:04PM +0200, Joachim Breitner wrote: > I think you once mentioned that ghc even contains (undocumented) code to > read package data from a directory. If that is the case (or if it can be > made the case), you could even skip the trigger and just have the > library packages dump their information in this directory. Non-packaged > libraries that the admin installs manually are still registered at the > usual place. ghc-pkg (and ghc) will then just merge these places (global > registry, user registry, directory with distribution files) as it now > merges the global and user registry.
I haven't tested how well that code would work yet. It would be dead simple from packaging POV. But it would provide no way for preserving information about hidden packages. A typo fix in the description would be enough to revert that if someone had set it that way. On the other hand, it just might not be worth it to even try to keep track of that. The usual Debian package semantics is that if you have something installed, then you are using it too. They could always remove the package instead of hiding it. For that matter, people don't have any sort of tracking of hidden cabal packages across versions outside of Debian packages, either. I haven't looked at it but I don't recall that haskell-devscripts' generated postinst scripts try to do it now, either. I may have been overengineering the case, again. Should we just go for revealing any hidden packages on update and put a note about that behaviour to ghc6's README.Debian? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
