This reverts commits
- 004c3f3c59
- 82faf2f006
- 5b0b5c8d3a
- c1356da2df
- 1f7f2e8907
Reason for revert: The descriptions are generated automatically and
would just be reverted on subsequent regenerations of
`hackage-packages.nix`. Such a regeneration is done in this commit to
clean up the diff of further regenerations.
PVP allows this update as non-breaking, so we anticipate Stackage
updating in the future (0.0.17 was uploaded a day after the latest LTS
snapshot) to unbreak comfort-glpk.
ghc and also ghcWithPackages (when taken from a haskell package set) are
a bit weird—in the same way stdenv is: ghc is actually from
buildPackages (pkgsBuildHost) wheras the main package set belongs to
pkgsHostTarget. ghc (and stdenv) is included in the package set due to
its special relation to the set: it is built by that ghc, so constituted
by the compiler in a manner of speaking.
For ghc this works in a straightforward way: It is packaged
independently from the haskell package sets and passed to
make-package-set.nix to create the different sets we expose.
With ghcWithPackages an error crept in, though: Since it needs to
receive the haskellPackages fix point (and thus can't be instantiated
before the package set), it is defined in make-package-set.nix. Here it
was neglected to make sure that it also has the same scope as ghc, i.e.
buildHaskellPackages/buildPackages: Otherwise the shell the wrapper
scripts use to invoke ghc (originally from buildPackages) would be from
pkgsHostTarget—in the cross case, the wrapper scripts would be
executable by neither host nor build platform. We want them to work on
the build platform, though.
Note that this creates a weird mismatch where it is hard to see which of
the alternatives would be more natural: ghcWithPackages and
ghcWithHoogle now use packages from the package set they are a member
of, but have *-ghc and hoogle executables that are executable on the
build platform. This works because ghc originates from buildPackages (as
discussed) and hoogleWithPackages is taken from buildHaskellPackages.
This does imply though that while set.ghcWithHoogle will be executable
on the build platform, set.hoogleWithPackages will be executable on the
host platform—both will use the fix point of set for the package
selector function. This is maybe a confusing asymmetry, but it seems
like a valid use case to cross-compile a hoogle instance. Most
development tools use ghcWithHoogle (or equivalent), so that use case is
covered as well in principle.
Should this be fixed on cache.nixos.org instead?
I would like that, but it won't be a complete fix, because the corrupted
NAR has already been accepted onto a number of hosts, which would need to
take manual action, if at all possible. Furthermore, I'd have to bother
people who have presumably have more important things to do; things that
actually have a lasting effect perhaps!
