Redefine "core packages"?

[snoyberg]

Right now, the definition of core packages is "things included in the global package database." However, it might be advantageous to redefine this to "packages that are wired into the compiler, and packages that depend on those." It seems like, with that definition, some packages will no longer be pinned down. Most importantly, that would include Cabal in GHC 7.10*.

Additional upside: if someone has installed extra packages in their global DB, they'd still be able to run a Stackage build. (Not a huge win, since only a few systems should be running the builds.)

Downside: this can lead to a situation where users have multiple versions of some packages installed (e.g., Cabal), which could be confusing. We've tried to avoid that so far.

One other thing for the record: the package I'm expecting to cause the most pain as far as being pinned down is binary. It would be nice if the binary used by GHC was renamed to ghc-binary (as was done in the past) to avoid this unnecessary pinning.

* Alternatively, or additionally, we could request that Cabal not be bundled with GHC 7.10.

[snoyberg]

Implemented in fpco/stackage-curator@2054a1f

[peti]

I'm not sure whether I understand this change. Cabal is both available in the global package database and it's wired into the compiler -- so it should be a core package according to both definitions, yet https://raw.githubusercontent.com/fpco/lts-haskell/master/lts-3.5.yaml says it's not. Also, what about the rts package? It's a core package as well, yet it's missing from the LTS build plans altogether.