"Simon Marlow"
There's another thing that bothers me though: when you install a package using hc-pkg, a number of checks are made:
1. there isn't already a package with that name/version
2. If the package is to be exposed, then the modules provided by the package don't overlap with another exposed package.
3. if an older version of the package is already exposed, then the older one is supposed to be hidden in favour of the new one
Since with the proposed change hc-pkg isn't running on the target system, it can't make any of these tests. GHC can detect at run-time that you have overlapping packages, but then it might not be possible to make changes to the package database (you might need to 'su' in order to do it).
The systems that would want to do this kind of thing, such as Debian, have other mechanisms for deciding whether packages conflict, etc. Over-all I'm kinda neutral about whether HC-pkg needs to be an opaque interface to the packaging system. What are the advantages to this? I'm going to write up a proposal about cabal interface changes, which is somewhat related, but also neutral to this. The only question to cabal proper is whether or not 'register' is guaranteed to run on the target. The rest of the LIP does indeed care about this, IMO, so we do need to decide. peace, isaac