Split ghc-boot so we have better dependency hygiene

At the moment, template-haskell transitively depends on bytestring. This means that any package which depends on template-haskell has its bytestring version pinned to the version that was shipped with GHC. Which is lame, because template-haskell doesn't actually use bytestring in any interesting way.

This is bad, we should split ghc-boot into two pieces, one which has the binary package database bits, and another which contains the Template Haskell bits, so we can have better dependency hygiene.

We should also have a comment on template-haskell mentioning the importance of dependency hygiene, so this doesn't happen again.

Trac metadata

Trac field	Value
Version	8.0.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	high
Resolution	Unresolved
Component	Core Libraries
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	RyanGlScott, bgamari, ekmett, hvr
Operating system
Architecture

changed milestone to %8.0.2

changed weight to 7

added Tbug Trac import core libraries labels

It's not only bytestring template-haskell started to depend on:

In GHC 7.10.3 there were the following deps:

"template-haskell-2.10.0.0" -> "base-4.8.2.0"
"template-haskell-2.10.0.0" -> "pretty-1.1.2.0"
"pretty-1.1.2.0" -> "base-4.8.2.0"
"pretty-1.1.2.0" -> "deepseq-1.4.1.1"
"pretty-1.1.2.0" -> "ghc-prim-0.4.0.0"
"deepseq-1.4.1.1" -> "array-0.5.1.0"
"deepseq-1.4.1.1" -> "base-4.8.2.0"

whereas with GHC 8.0 we have now

"template-haskell-2.11.0.0" -> "base-4.9.0.0"
"template-haskell-2.11.0.0" -> "ghc-boot-8.0.0.20160511"
"template-haskell-2.11.0.0" -> "pretty-1.1.3.3"
"pretty-1.1.3.3" -> "base-4.9.0.0"
"pretty-1.1.3.3" -> "deepseq-1.4.2.0"
"pretty-1.1.3.3" -> "ghc-prim-0.5.0.0"
"deepseq-1.4.2.0" -> "array-0.5.1.1"
"deepseq-1.4.2.0" -> "base-4.9.0.0"

"ghc-boot-8.0.0.20160511" -> "base-4.9.0.0"
"ghc-boot-8.0.0.20160511" -> "binary-0.8.3.0"
"ghc-boot-8.0.0.20160511" -> "bytestring-0.10.8.0"
"ghc-boot-8.0.0.20160511" -> "directory-1.2.6.2"
"ghc-boot-8.0.0.20160511" -> "filepath-1.4.1.0"
"binary-0.8.3.0" -> "array-0.5.1.1"
"binary-0.8.3.0" -> "base-4.9.0.0"
"binary-0.8.3.0" -> "bytestring-0.10.8.0"
"binary-0.8.3.0" -> "containers-0.5.7.1"
"directory-1.2.6.2" -> "base-4.9.0.0"
"directory-1.2.6.2" -> "filepath-1.4.1.0"
"directory-1.2.6.2" -> "time-1.6.0.1"
"directory-1.2.6.2" -> "unix-2.7.2.0"

so effectively, template-haskell now transitively adds the following dependencies (relative to GHC 7.10.3):

• unix
• directory
• filepath
• containers
• bytestring
• binary

this reduces a lot of flexibility from the cabal solver, and makes it impossible to use newer versions of those packages (something I did frequently in GHC 7.10.3) as soon as template-haskell enters install-plans.

I'm all for it!

changed milestone to %8.0.1

changed weight to 10

assigned to @bgamari

see eed820b6

Trac metadata

Trac field	Value
Version	8.0.1 → 8.0.1-rc4
Priority	high → highest

I like the direction of travel here, but I do beg for a wiki page or clearly-signposted summary somewhere that explains

• What packages there are
• What they contain
• Crucially, what the thinking behind the architecture is

For example, summarising what is in ghc-boot-th, and what criteria guided that choice. Similarly ghc-prim. Etc.

There is some stuff already

• Repositories
• Commentary/Libraries

mentioned in issue #12078

closed

Explained this a bit in [[Commentary/Libraries#GHC-internallibrariesghc-boot-]]

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added Phighest label