RE: proposal for ghc-pkg to use a directory of .conf files
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.
OK, just send us a patch and if there are no objections we can merge it into the HEAD.
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. The advantages of this abstraction are the usual ones: we might want to change the representation, and the ghc-pkg tool provides a good place to add backwards compatibility if necessary. However, I'm prepared to be persuaded. The "just put a file in this directory" approach to installation is very compelling, being much more transparent. But bear in mind that if we pick this route, then backwards compatibility has to be built into the file format (I think it might be already, but we're planning changes in this area to better support Cabal). Also, there needs to be a way to find the location to install the file - asking ghc or ghc-pkg is the usual way. Cheers, Simon
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
participants (2)
-
Duncan Coutts -
Simon Marlow