On Mon, 2004-11-08 at 14:36, Simon Marlow wrote:
On 06 November 2004 10:10, Sven Panne wrote:
Duncan Coutts wrote:
I can knock up a proof of concept patch if anyone thinks this is a good idea. It should be totally backward compatible, it's ok to use both, but ditro packagers might like to enforce a policy of using a directory of package files for external libraries.
In some ways this looks like a good idea, but it contradicts some of the ideas in the Cabal proposal. There, we were treating the package database as an abstract entity hidden behind the ghc-pkg interface. All interaction with the database would be done via ghc-pkg.
There's no reason why we can't do both. You can register a package using ghc-pkg and it can create a separate file in a package conf directory (after expanding env vars and doing auto ghci libs if necessary). The standard way to build binary packages for Linux/BSD distros is to build and install into a temporary directory, then the package manager tars up those files and merges them into the filesystem on the target machine. The package manager remembers all the files it merged so it can removed them or upgrade them later. We can use ghc-pkg at the build / install-into-temp phase to create the $(package).conf files under $TMP_INSTALL_ROOT/usr/lib/ghc-$VER/package.conf.d/ and then final installation is jsut merging files without any post-install calls to ghc-pkg to modify installed files (ie the global ghc package.conf file) So we can still keep the abstraction of $HC-pkg and gain simpler packaging stuff. Duncan