All, Yet again I've got annoyed by the difficulties with the way ghc registers packages. It's hard to get right. This time I had someone testing hdbc-odbc for me on ppc64. He uninstalled ghc and reinstalled it (to pick up a fix I had made) then he found that building hdbc-odbc failed because the hdbc package was not registered. However portage (the Gentoo package management facility) knew that it was installed. Of course what happened is that when ghc was reinstalled all the ghc packages that were already installed were not re-registered. Actually that is my fault because our ghc ebuild is supposed to do this. (Technically to do this correctly we should re-register the packages in dependency order, but we don't and just use --force) The point is that there are several bits that the packaging system has to get right for this to all work. The majority of the code in our ghc-package.eclass is for dealing with this issue. If we could just have ghc use a directory of package files rather than registering via modifying one central file then this would all become much simpler and more robust. One concern is that it would remove a point where the package database can be checked for consistency. I don't think this is necessarily so. The place that this QA check is really important is when users are manually installing packages. If an package management system finds a QA problem at registration time then it's already an unrecoverable bug. So the ghc-pkg could continue to be used in the way it is now, it will do it's carious checks and then install a file into a global package.conf.d directory rather than modifying a global package.conf file. For distro packaging systems we could use "ghc-pkg --check" or something, and then the package system would take responsibility for actually installing the file (and removing it when the package is uninstalled/upgraded). I'm somewhat tempted to patch our current ghc to do this, it might be easier to get that working than to get our current hacks to work properly. Duncan