On 09 November 2004 17:36, Isaac Jones wrote:

"Simon Marlow" writes:

...

On 08 November 2004 18:47, Duncan Coutts wrote:

...

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.

Ok, sounds reasonable.

I'm going to be working on the package support in ghc and ghc-pkg to improve support for Cabal, so let's do this at the same time.

As a Debian packager, I like the idea of changing the way HC-PKG handles individual packages.

The question in my mind is whether we want to execute any code on the install target. Previously, I have thought of "./setup register" as being a step that happens on the target, no matter what. So if Marcus Makefile wants to do something specifically for the target at install time, this is where he could do it.

If we go this route and have the package registration happen at install-in-temp time, then we don't have any standard way to run a post-install script. Some people may prefer that we never execute anything from Cabal on the target, but I would prefer to leave that ability.

One solution would be to move the registration step into install-into-temp time, as above, but to add another standard command to Cabal like "./setup postinstall" and maybe some others "preinst, prerm, postrm" as in Debian.

This would solve both problems; haskell packages installed with a packaging system like Debian would usually just be moving files into place, but if Marcus or Angela really needed to run something on the target, this is how they'd do it.

If ./setup register isn't going to run at install time, then I agree we might want ./setup postinst too. 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). Cheers, Simon