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

[Simon Marlow]

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

> "Simon Marlow" <simonmar at microsoft.com> 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