Limiting size of global package database
michael at snoyman.com
Wed Dec 31 14:32:00 UTC 2014
On Wed Dec 31 2014 at 4:25:12 PM Herbert Valerio Riedel <hvriedel at gmail.com>
> Hello Michael,
> On 2014-12-31 at 15:10:37 +0100, Michael Snoyman wrote:
> > tl;dr: Now that ghc (the library) doesn't depend on Cabal (the library),
> > can we remove Cabal from the global package database installed with GHC?
> > For both of these reasons, I think we should limit the number of packages
> > included in the global package database. One seemingly small step we
> > do on that front is not include extraneous packages. In GHC 7.10rc1, that
> > includes Cabal and xhtml:
> btw, haskeline and terminfo should be considered as well, according to
> your argument.
Yes, I didn't mean to imply that my list was exhaustive, those were just
two examples that jumped out at me.
> > both packages are in the global package database, but could just as
> > easily be removed from there and installed by users. The motivation
> > for that would be to avoid problem (1) above.
> However, as for xhtml, haskeline and terminfo, we had to register/expose
> them in the global pkg DB due to
IIUC, this comes down to the fact that distros want to install all packages
into the global database, whereas the pain point I'm describing here is
from users wanting to *avoid* having things in the global database. Perhaps
there's a simple solution here: if end-users non-distro installations of
GHC unregistered those packages, would it cause them any problems? Perhaps
having those packages in the global database is something that *only*
> and as for Cabal, I have been told (maybe Duncan can weigh in...?) that
> Haskell implementations need to provide it (together with a `*hc-pkg`
> executable) in order to conform to the CABAL specification.
If that's the case, I would request that we modify the CABAL specification.
I wouldn't want us to make a bad technical decision because a spec told us
to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs