Limiting size of global package database
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? A problem that comes up quite a bit for users of GHC is conflicting package versions versus the version of a package that shipped with GHC. Some examples I've run into in the past include binary-0.7/GHC-7.6, and bytestring0-0.10/GHC-7.4. This is problematic for two reasons: 1. End users can be confused by having multiple versions of a package installed (one global, one user). I've seen at least a dozen questions on Stack Overflow, Reddit, and mailing lists about things like "ByteString is not bytestring-0.10.0.0-Data.ByteString.Internal.ByteString". 2. Any packages depended on by the ghc package can be very dangerous to upgrade, as then you're blocked from using the ghc package with the new version. This most often comes into play with doctest, though I've been affected by it on other projects as well. 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: 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. I realize that this change wouldn't affect point (2) above at all. Frankly, that's the issue that causes me quite a bit more trouble, and I'd love to see it resolved somehow, but it's unlikely to occur during the GHC 7.10 window. I'm writing this email now because I think there's a chance of resolving the smaller issue immediately, but I'd like to explore the wider issue of ghc-the-library dependencies for GHC 7.12. I've opened up an issue[1] on Stackage's issue tracker about this as well. [1] https://github.com/fpco/fpco/issues/3978
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.
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 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]. Cheers, hvr [1]: https://www.haskell.org/cabal/proposal/pkg-spec.pdf
On Wed Dec 31 2014 at 4:25:12 PM Herbert Valerio Riedel
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
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
Hi Herbert,
On 31 December 2014 at 15:25, Herbert Valerio Riedel
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.
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
Thanks for pointing to the root explanation. Though as noted in that ticket by Joachim, there was another solution to this problem: simply install DSO's in a location that wouldn't clash with where distros typically install packages themselves. The other solution is to simply statically link the GHC binaries that would otherwise require these DSO's. Is the reason why those solutions were not chosen in the end documented anywhere? As Michael points out, every additional package forcefully installed into the global db by GHC is yet another potential source of problems for users when installing libraries. Including when doing so in a sandbox! (because global packages leak inside sandboxes). Best, Mathieu
participants (3)
-
Herbert Valerio Riedel -
Mathieu Boespflug -
Michael Snoyman