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

[Isaac Jones]

"Simon Marlow" <simonmar at microsoft.com> writes:

(snip)
> 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).

The systems that would want to do this kind of thing, such as Debian,
have other mechanisms for deciding whether packages conflict, etc.

Over-all I'm kinda neutral about whether HC-pkg needs to be an opaque
interface to the packaging system.  What are the advantages to this?

I'm going to write up a proposal about cabal interface changes, which
is somewhat related, but also neutral to this.

The only question to cabal proper is whether or not 'register' is
guaranteed to run on the target.  The rest of the LIP does indeed care
about this, IMO, so we do need to decide.


peace,

  isaac