Limiting size of global package database
Michael Snoyman
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>
wrote:
> 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
> could
> > 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
>
> https://ghc.haskell.org/trac/ghc/ticket/8919
>
>
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*
distros need.
> 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[1].
>
>
>
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.
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141231/c5ce8822/attachment.html>
More information about the ghc-devs
mailing list