Having a single package database for all Haskell implementations seems a hard thing to implement: when GHC is installed, it will have to check whether the database and haskell-config already exist, and similarly for the other Haskell implementations. When a Haskell system is deinstalled, it has to decide whether to de-isntall haskell-config and the package database.
I don't think that's so bad. Figuring out if a package database already exists should be a matter of having an agreed upon System.Directory.systemConfigDir. Then maybe the package database itself can tell you where to find haskell-config.
What about multiple versions of GHC installed on a system, each with different sets of packages installed? Can I still install GHC in my own home directory, without needing to modify files in /etc?
I think that the compilers / interpreters installed on the system will also be stored in the "package config" database. If you're deinstalling yourself, the package database can tell you whether you're the only compiler left and thus whether to get rid of haskell-config.
That said, I think there are still issues with having a single package database, for instance, what if a package configuration for one Haskell Implementation has a field that conflicts with the package configuration for another implementation. Yuck! But maybe that won't come up. For instance, right now there are separate flags for ghc, nhc, and hugs opts, and probably there should be flags for shared opts.
Also, there doesn't seem to be provision in the package configuration for naming libraries specific to a particular implementation (eg. to use this package on GHC you must link in libHSwibble.a from /foo/bar, but on nhc98 you link in libHSnhc_wibble.a from ...). It seems to me that every field needs to be duplicated for each compiler installation; either that or you could put the compiler name in the package identifier, so you'd have packages like "ghc-6.2-base-1.0", "nhc98-1.3-base-1.0". Incedentally, GHC never uses the extra_ghc_opts in the package configuration. In fact, I don't think it should be there: it doesn't make sense in conjunction with auto packages (if I don't know whether I'm using a package or not, I don't know whether to add the flags). The flags fields should be disabled if auto is True.
I'd rather just admit that the Haskell systems are separate, and each provides its own implementation of Distribution.Package. Yes, this means that if you run Setup.lhs with Hugs it is different than running it with GHCi: if I want to install a package for GHC I have to run the Setup.lhs script using GHC.
I think this would dash my hopes of being able to install a package with a single command. The idea so far has been to have some kind of haskell-interactive / runhugs-type executable /usr/bin/haskell which will execute the setup script to install and configure the package based on the already-installed compilers.
It doesn't prevent you doing this. Here's how it might work: - Each compiler has their own package database, and their own implementation of Distribution.Package with an implementation-defined location for the package database(s). - There is a suite of tools, including haskell-config and /usr/bin/haskell, which are installed only once. These tools know about all the installed compilers on the system. We could install these tools with a compiler, or separately; installs/deinstalls of compilers need to update some state so that the tools are aware. - /usr/bin/haskell could run the script it is given using each compiler on the system, if that's what you want. eg. $ /usr/bin/haskell script.hs -- runs script.hs using the default compiler $ /usr/bin/haskell --all script.hs -- runs the script using each compiler on the system so to do an installation for all compilers, you say './Setup.lhs --all --install', assuming that Setup.lhs begins with '!#/usr/bin/haskell'.
Likewise, when you install a new compiler, it knows about what packages are there already for the other ones and might take a crack at building them for itself.
This isn't so far fetched: elisp for emacs and xemacs already do something similar on Debian at least.
We can aim for this in the long term if you like - I still believe this is something that the package management system should do for us, though. The end result is the same, and it's a lot less work. Cheers, Simon