And there's a problem: ghc-pkg uses Read, and that requires all the fields to be there. It would be a Bad Idea to force everyone to update every single package.conf file out there. Is there any special reason why it doesn't use the ParsePkgConf.y parser from compiler/main? (Simon: Am I allowed to make it do so?)
Sure, go ahead. That's been on my ToDo list for a while. I'm beginning to think that the way MacOS X does frameworks is the way we should have done packages: it's much simpler to install/remove packages ("xcopy install" in MS-speak) if they all hang off a common root. On the other hand, it wouldn't be possible to install packages in some non-standard place without giving GHC an extra flag each time you use the package.
One interesting possibility would be to allow support for .hi files in frameworks. This would mean GHC would look inside frameworks specified by the -framework flag and "frameworks" package.conf entries for .hi files, in addition to -I and "import_dirs".
I don't see why I would want to add a Haskell-Framework to a package.conf file... I would definitely like to be able to drag&drop-install GHC-Packages (it could be done on all platforms, not only MacOS). It would require loading package.conf files from framework-style directories - I'll take a look at whether this could be done easily (and without disturbing the existing system) when I've got the more important things done.
This does indeed sound useful, and perhaps it could co-exist with the existing global package.conf file: if a package isn't found in package.conf, then we just search the framework/package search path for <package>/pkg.conf. I'm sure this would make people distributing 3rd party packages happier. Cheers, Simon