registering packages in ghc using a directory of package files

[Duncan Coutts]

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