proposal for ghc-pkg to use a directory of .conf files

[Duncan Coutts]

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