Core packages can be incorrect?
tfausak opened this issue · 1 comments
I'm not at all familiar with the Stackage curator, so I apologize if this is not the correct repository. I was brought here more or less by a Reddit thread.
As far as I can tell, the Stackage curator is responsible for coming up with a list of so-called "core" packages. That's what the getCorePackages function does. A core package is anything that ghc itself depends on. The list of dependencies comes from ghc-pkg describe, which spits out a package specification.
This all makes sense to me, but I think there's a problem with it: If the Stackage curator is run with a different version of GHC than the resolver, the list of core packages could be different. I assume that ghc's dependencies don't change all that often, but I do get different results based on the compiler version.
| 7.10.2 | 7.10.3 | 8.0.1 | 8.0.2 | 8.2.0.21070507 |
|---|---|---|---|---|
| array | array | array | array | array |
| base | base | base | base | base |
| . | . | binary | binary | binary |
| bin-package-db | bin-package-db | . | . | . |
| bytestring | bytestring | bytestring | bytestring | bytestring |
| containers | containers | containers | containers | containers |
| . | . | . | deepseq | deepseq |
| directory | directory | directory | directory | directory |
| filepath | filepath | filepath | filepath | filepath |
| . | . | ghc-boot | ghc-boot | ghc-boot |
| . | . | . | ghc-boot-th | ghc-boot-th |
| . | . | ghci | ghci | ghci |
| hoopl | hoopl | hoopl | hoopl | hoopl |
| hpc | hpc | hpc | hpc | hpc |
| process | process | process | process | process |
| template-haskell | template-haskell | template-haskell | template-haskell | template-haskell |
| . | . | . | . | terminfo |
| time | time | time | time | time |
| transformers | transformers | transformers | transformers | transformers |
| unix | unix | unix | unix | unix |
Is this a problem?
No, there's no problem. We discussed this a bit on Slack, and:
- stackage-curator expects the correct version of GHC to be on the PATH, and checks that this happens
- It also correctly identifies deepseq as a core package
We could argue about whether the current behavior of Stack regarding rebuilding of core packages is a good idea or not for the GHC release candidate use case, but that's orthogonal to this discussion.